JP2004153782A - Method of negotiation to digital item adaptation (dia) - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide digital item adaptation, especially MPEG-21 digital item adaptation (DIA) which requires negotiation between different MPEG-21 peers. <P>SOLUTION: Advertisements metadata is defined to hold digital item adaptation descriptions, such as Usage Environment description, BSDL description, XDI description as well as MPEG-7 Media description in its descriptions element. With that, a generic and higher-level DIA negotiation message independent of any arbitrary network protocol is also defined, so that descriptions for digital item adaptation can be directly included in the defined messages for registering, transmitting and updating to fulfill DIA description negotiation in those applications involved in digital item adaptation. <P>COPYRIGHT: (C)2004,JPO

Description

【００４７】
ＨａｎｄｌｅｒＮａｍｅ（ハンドラ名）：この問合せを処理する方法を規定するストリング。
ＳｃｒＰｅｅｒＩＤ：問合せを発したピアのＩＤ。
ＱｕｅｒｙＩＤ：問合せＩＤ。本ＩＤは、この問合せに対する応答に含まれるべきである。
Ｑｕｅｒｙ：問合せ構造。
【００４８】

【００４９】
ＨａｎｄｌｅｒＮａｍｅ：応答を処理する方法を規定する。
ＱｕｅｒｙＩＤ：これが応答する問合せのＩＤ。
Ｒｅｓｐｏｎｓｅ：応答構造
【００５０】
Ｅｎｄｐｏｉｎｔ Ｒｏｕｔｉｎｇ（エンドポイント・ルーティング）：ネットワークの定義されたプロトコルの接続は、過渡的であり得るし、かつメッセージ・ルーティングは非決定的である。ここでのエンドポイント・ルーティングは、その宛先へのピア・ルート・メッセージを支援するためにルーティング・サービスによって処理される一組の要求／問合せメッセージを定義する。ピアが所定のピア・エンドポイント・アドレスにメッセージを送ることを求められたときは、それがこのピアへのルートを有する場合、ピアは、そのローカル・キャッシュを調べる。ルートが見付つからなかった場合、ルート情報を求めるその利用可能なピア・ルート・ルータにルート・リゾルバ問合せメッセージを送る。ピア・ルータは、ルート情報をキャッシュするための能力を提供すると共に、異なる物理的又は論理的ネットワークをブリッジする。ピア・ルータは、ルートの問合せを受取ると、宛先を知っている場合には、ホップの一覧表としてのルート情報を返送することによって問合せに回答する。メッセージは、第１のルータに送ることができ、かつ、そのルータはルート情報を用いて宛先ピアにメッセージをルーティングする。任意のポイントで、ルート情報は、役に立たなくなり、現行のルータに新しいルートを見付けることを要求する。ここで定義されたエンドポイント・ルータは、ルートを操作し、かつ更新するためにユーザにより定義されたルーティング・サービスに必要なフックを供給することを意図する。二つの通信しているピアは、それらのネットワーク・ロケーションに依存してメッセージを送るためにピア・ルータを用いる必要がある。ピア・ルータはルート情報を一般にキャッシュする。ピアは、ルート情報についてピア・ルータに問合せることができる。ピア・ドメイン内のピアはピア・ルータになり得る。
【００５１】

【００５２】
ＤｅｓｔＰｅｅｒＩＤ：宛先ピアのＩＤ。
Ｃａｃｈｅｄ：応答がキャッシュされた応答でありうるときには真；応答がキャッシュからきてはいけないときには偽である。
【００５３】

【００５４】
ＤｅｓｔＰｅｅｒＩＤ：宛先ピアのＩＤ。
ＲｏｕｔＰｅｅｒＩＤ：宛先ピアへのルートを知っているルータのピアＩＤ。
ＡｄｖＭｅｔａｄａｔａ：ルーティングするピアのアドバタイズメント・メタデータ。
ＧａｔｅｗａｙＩＤ：ゲートウェイのシーケンスＩＤ。
【００５５】
Ｃｈａｎｎｅｌ Ｂｉｎｄｉｎｇ（チャネルビンディング）：チャネルビンディングは、その他のピアと通信するために、アプリケーション及びサービスによって用いられる。チャネルは、二つのエンドポイント間のバーチャル・チャネルである。チャネルビンディングは、ＨＴＴＰ、ＴＣＰ／ＩＰ又はＴＬＳトランスポートのような、様々なトランスポート・プロトコルを用いることができる。チャネルは、アブストラクトネームドメッセージ・キュー（ａｂｓｔｒａｃｔ ｎａｍｅｄ ｍｅｓｓａｇｅ ｑｕｅｕｅ）として見ることができ、生成、オープン／リゾルブ（バインド）、クローズ（アンバインド）、削除、送信、受信の動作をサポートする。複数のビンディング問合せメッセージが送信されてもよい。一つ又は複数の応答が受信されてもよい。応答が受信されなくてもよい。
【００５６】

【００５７】
ＣｈａｎｎｅｌＩＤ：リゾルブされるチャネルＩＤ。
Ｃａｃｈｅｄ：応答がキャッシュされた応答であり得るときには真である。回答がキャッシュから生じてはならない場合には偽である。要求者は、情報がキャッシュから取得されないことを求めることができる。これは、古い接続をアドレスするために、ピアから最新情報を取得するためである。
ＰｅｅｒＩＤ：ピアＩＤを付与する。応答が期待されるピアのみのピアＩＤを特定する。全てのその他のピアからの応答は無視される。これは、チャネル・ビンディング・リクエストへの応答がピアによってなされることを保証しない。
【００５８】

【００５９】
ＣｈａｎｎｅｌＩＤ：解明されるチャネルＩＤ。
Ｆｏｕｎｄ：入力チャネルが特定されたピアで見付かったかどうかを示すために用いられる。
ＰｅｅｒＡｄｖＭｅｔａｄａｔａ：入力チャネルが解明されたピアのアドバタイズメント・メタデータ。
【００６０】
Ｐｅｅｒ Ｄｉｓｃｏｖｅｒｙ（ピア・ディスカバリ）：ピア・ディスカバリは、公開されたピア・リソースを発見し、かつまたそれ自体のリソースを公示するために用いられる。リソースは、アドバタイズメント・メタデータとして表わされる。ピア・ディスカバリは、ピアに、そのドメイン内のメタデータを検出することを可能とする。意図は、高レベルなディスカバリ・サービスを構築するための基本的なディスカバリ・インフラストラクチャを供給することである。多くの状況では、ディスカバリ情報は、サービスがドメイン・トポロジーのより良い知識を有しうるので、高レベルなサービスによってより良く知られる。ピア・ディスカバリは、アドバタイズメント・メタデータを発見するための基本メカニズムを基本的に供給し、同時にフックを供給してそのような高レベルなサービス及びアプリケーションは、ディスカバリ処理に参加することができる。
【００６１】

【００６２】
Ｎｕｍｂｅｒ：応答するピアのアドバタイズメント・メタデータの最大数を特定する。
Ａｔｔｒｉｂｕｔｅ及びＶａｌｕｅ：ネーム属性及び値の要素を含むメタデータのみが検出することができる。
ＰｅｅｒＡｄｖＭｅｔａｄａｔａ：要求しているピアのアドバアタイズメント・メタデータ。
Ｕｐｄａｔｅ：ＰｅｅｒＡｄｖＭｅｔａｄａｔａにおいて転送されたＤＩＡ記述がちょうど更新された記述である（真）か又は完全な記述（偽）であることを示す。
【００６３】

【００６４】
Ｎｕｍｂｅｒ：受信した応答要素の数を特定する。
Ａｔｔｒｉｂｕｔｅ及びＶａｌｕｅ：ディスカバリ問合せ（ＤｉｓｃｏｖｅｒｙＱｕｅｒｙ）に対する応答であることを反映する。
ＰｅｅｒＡｄｖＭｅｔａｄａｔａ：応答するピアのアドバアタイズメント・メタデータ。
Ｕｐｄａｔｅ：ＰｅｅｒＡｄｖＭｅｔａｄａｔａ内の転送されたＤＩＡ記述がちょうど更新された記述である（真）か又は完全な記述（偽）であることを示す。
Ｒｅｓｐｏｎｓｅ：応答構造
【００６５】
１．２ ＸＭＬスキーマ・ベース型メタデータ
ＸＭＬスキーマで与えられるアドバタイズメント・メタデータは、ピア、ピア・ドメイン、チャネル、メディア・リソース、サービス及び多くのその他のタイプのリソースを記述するために用いられる。メディア・リソース（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ）を適応するために必要な情報を供給することを意図したＤＩＡ記述は、ここではアドバタイズメント・メタデータ内に配置される。定義されるプロトコルは、そのようなキー情報にしたがい定義され、ピア間でそのようなメタデータを通過させるために使用される。
【００６６】
アドバタイズメント・メタデータ・記述・スキーマ及びそれらのセマンティクスを以下に示す。
【００６７】

【００６８】
Ｎａｍｅ：これは、ピア、ピア・ドメイン、チャネルに関連付けることができる選択的なストリングである。ネームの一意性を保証する集中ネーミング・サービスから取得されなければ、ネームは一意であることを必要としない。
ＰｅｅｒＩＤ：これは、ピアを一意に特定する要素である。
ＰｅｅｒＤｏｍａｉｎＩＤ：この要素は、ピア・ドメインＩＤ（Ｐｅｅｒ Ｄｏｍａｉｎ ＩＤ）を提供する。各ピア・ドメインは、一意のＩＤを有する。
ＣｈａｎｎｅｌＩＤ：これは、チャネル（Ｃｈａｎｎｅｌ）を一意に特定する要素である。
Ｄｅｓｃｒｉｐｔｉｏｎ：これは、詳細なＤＩＡ記述・メタデータを付与するために用いることができる選択的な任意のタイプの要素である。
Ｓｅｒｖｉｃｅ：本要素は、そのクラス（Ｃｌａｓｓ）によって示されるドメイン・サービスと指定された任意のパラメータとの間の関連を記述する。また、サービス・セクション（Ｓｅｒｖｉｃｅ Ｓｅｃｔｉｏｎ）は、このサービスが使用不能であることを意味する要素をオプションで含んでもよい。本要素は、ピアの所有者によってなされる構成上の選択を伝達するために用いられる。
【００６９】
最後に、図２及び図３に、ＤＩＡ記述更新の場合のＤｉｓｃｏｖｅｒｙＱｕｅｒｙ（ディスカバリ問合せ）及びＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅ（ディスカバリ応答）ＸＭＬメッセージの例をそれぞれ示す。図１のインターネットにおける携帯電話クライアントとデジタル・マルチメディア・サーバは相互に知っており、有線及び無線ネットワークを介して、ピア・リゾルバ（Ｐｅｅｒ Ｒｅｓｏｌｖｅｒ）、エンドポイント・ルータ（Ｅｎｄｐｏｉｎｔ Ｒｏｕｔｅｒ）、チャネル・ビンディング（Ｃｈａｎｎｅｌ Ｂｉｎｄｉｎｇ）メッセージを送ることによってそれらの間の有効な接続をセットアップしている。サーバは、“属性（ａｔｔｒｉｂｕｔｅ）”及び“値（Ｖａｌｕｅ）”が合致する全ての携帯電話にピア・ディスカバリ（Ｐｅｅｒ Ｄｉｓｃｏｖｅｒｙ）・メッセージを送り、それらのＤＩＡ更新応答、例えば図３に示したＤＩＡ“ディスプレイ”エレメント更新の取得を試みる。
【００７０】
２．ＸＭＬスキーマを用いた分散したピア間の汎用ＤＩＡネゴシエーションメッセージ
ＭＰＥＧ−２１で定義されるＤＩＡネゴシエーションは、汎用的方法により一般のネットワークを介してＤＩＡメタデータを転送するピア・ツー・ピアを対象にする。オープン・ネットワーク・プラットフォームは、ピア・ツー・ピア・コンピューティングに対して設計することができる。携帯電話及び無線ＰＤＡからＰＣ及びサーバ／ゲートウェイ／プロキシまでの範囲にわたるネットワーク上の接続された機器による、ピア・ツー・ピア方式での通信及び協働を可能とする一組のオープン・プロトコルは、例えば、セクション１のピア・リゾルバ（Ｐｅｅｒ Ｒｅｓｏｌｖｅｒ）、エンドポイント・ルーティング（Ｅｎｄｐｏｉｎｔ Ｒｏｕｔｉｎｇ）、ピア・ディスカバリ（Ｐｅｅｒ Ｄｉｓｃｏｖｅｒｙ）、及びチャネル・ビンディング（Ｃｈａｎｎｅｌ Ｂｉｎｄｉｎｇ）が定義され得る。協同利用可能な方法での、ＤＩＡ記述ネゴシエーションに対する別の解決策は、ＤＩＡ記述・メタデータを格納するより高いレベルの汎用ＤＩＡ記述ネゴシエーションメッセージを定義することである。セクション１．２で定義されたアドバタイズメント・メタデータは、ＤＩＡ記述・メタデータを保持する必要がない。これらのネゴシエーションメッセージの全ては、定義された汎用プロトコルの上位レイヤ及び／又はＨＴＴＰ／ＴＣＰ／ＩＰのような通常存在している最も低いレイヤの物理ネットワークプロトコル上で設計することができる。この概念を図４に示す。
【００７１】
モジュール４．１は、ＵＲＩによってアクセスすることができるか又はネゴシエーションメッセージにおいてペイロード（ＤＩＡＤｅｓｃｒｉｐｔｉｏｎＤａｔａ）として格納され得るな使用環境（Ｕｓａｇｅ Ｅｎｖｉｒｏｎｍｅｎｔ）、ＸＤＩ（コンテキスト・デジタル・アイテム（Ｃｏｎｔｅｘｔ Ｄｉｇｉｔａｌ Ｉｔｅｍ））、ＢＳＤＬ（ビットストリーム構文記述言語（Ｂｉｔｓｔｒｅａｍ Ｓｙｎｔａｘ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ））記述等を含むＤＩＡ記述である。モジュール４．２、４．３、４．４は、ＤＩＡネゴシエーションに対するメッセージ、ピア・ツー・ピア通信に対するプロトコル、及び物理ネットワーク・トランスポートをそれぞれ定義するネゴシエーションメカニズムに対する個別のレイヤである。モジュール４．５は、ＤＩＡネゴシエーションに対して最も高いレイヤのモジュール４．１のＤＩＡ記述を格納する３つの汎用メッセージ（ＤＩＡＲｅｇｉｓｔｅｒ、ＤＩＡＴｒａｎｓｍｉｔ、及びＤＩＡＵｐｄａｔｅ）を与える。また、ネゴシエーションメッセージのフローチャートを図５に示す。
【００７２】
モジュール５．１は、標準化ＤＩＡ記述・スキーマに基づく、使用環境、ＸＤＩ（コンテキスト・デジタル・アイテム）、ＢＳＤＬ（ビットストリーム構文記述言語）記述を含むピアＡに対する生成ＭＰＥＧ−２１ ＤＩＡ記述を示す。
【００７３】
モジュール５．２は、ピアＡがピアＢに対し現行のＤＩＡ記述を伝送または更新することを望むときに、ピアＡが登録（又は伝送、更新）メッセージを構築することを示す。登録メッセージは、一のピアから他のピアへＤＩＡ記述の登録を要求するために使用される。伝送メッセージは、ピア間の通信のために詳細な端末仕様を送信するために使用される。更新メッセージは、一のピアの端末情報が変更されたときに、その端末情報の変更を一のピアから他のピアへ通知するために使用される。
【００７４】
モジュール５．３は、ピアＡが、ピアＢに対し、ピアＡに関するＤＩＡ記述により登録（又は伝送、更新）メッセージを送信することを示す。
【００７５】
モジュール５．４は、ピアＢが、ピアＡに対する“応答”情報により登録（又は伝送、更新）のための応答メッセージを構築することを示す。
【００７６】
モジュール５．５は、ピアＢが、ピアＡへの“応答”情報により登録（又は伝送、更新）のための応答メッセージを返送することを示す。
【００７７】
ピアＡは、ピアＡとピアＢの間のＤＩＡ記述ネゴシエーションが成功したかどうかを知るため、応答メッセージ内の“応答”情報に含まれる値（ｖａｌｕｅ）をチェックする、これをモジュール５．６に示す。“応答”情報の値が“真”である場合、モジュール５．７に示すように、それは、ピアＢが、ピアＡからの登録を受け入れ、かつ、ピアＡの新規のＤＩＡ記述又は更新するＤＩＡ記述のいずれかに対し、ＤＩＡ記述をピアＡから受け取る準備ができていることを示す。また、“応答”情報の値が“偽”である場合、モジュール５．８に示すように、それは、ピクチャＢがピアＡからの登録を拒否し、かつピアＡからＤＩＡ記述を受け取ることを望まないか、又は、新規のＤＩＡ記述もしくは更新するＤＩＡ記述を受け取ることについて問題を有していることを示す。
【００７８】
図６に示す、ＤＩＡ記述ネゴシエーションメッセージ・スキーマのシンタックス及びセマンティクスを以下に示す。
【００７９】

【００８０】
Ｔｙｐｅ：“ＤＩＡＲｅｇｉｓｔｅｒｉｎｇ”、“ＤＩＡＴｒａｎｓｍｉｔｔｉｎｇ”、及び“ＤＩＡＵｐｄａｔｉｎｇ”のような、ＤＩＡネゴシエーションメッセージ・タイプを示す。
ＤＩＡＲｅｇｉｓｔｅｒｉｎｇ：ピアが現行ＤＩＡ記述を伝送または更新することを試みるときにＤＩＡ記述を登録するために用いるメッセージ・タイプ。
ＤＩＡＴｒａｎｓｍｉｔｔｉｎｇ：現行ピアＤＩＡ記述を伝送するために用いるメッセージ・タイプ。
ＤＩＡＵｐｄａｔｉｎｇ：現行ピアＤＩＡ記述を更新するために用いるメッセージ・タイプ。
Ｍｓｇ＿ＩＤ：メッセージ発信者によって規定されるメッセージ識別子。メッセージに応答して送られた全てのメッセージは、オリジナル・メッセージの識別子を含まなければならない。
ＳｅｎｄｅｒＰｅｅｒ＿ＩＤ：メッセージの発信者のピアＩＤを示す。
ＲｅｃｉｐｉｅｎｔＰｅｅｒ＿ＩＤ：メッセージの意図した受信者のピアＩＤを示す。
ＤＩＡＤｅｓｃｒｉｐｔｉｏｎ：使用環境記述、ＢＳＤＬ記述、ＸＤＩ（ＤＩＤでラップされたセッション・モビリティに対するＤＩＡ記述）のような、伝送、交換または更新することが必要な全てのデジタル・アイテム・アダプテーション記述。ＤＩＡＤｅｓｃｒｉｐｔｉｏｎは、ペイロード“ＤＩＡＤｅｓｃｒｉｐｔｉｏｎＤａｔａ”としてメッセージに含ませることができるか、又はワールド・ワイド・ウェブに配置されるＤＩＡ記述のエンティティを指定するために“Ｒｅｆｅｒｅｎｃｅ”を用いることができる。
Ｒｅｓｐｏｎｓｅ：同じ“Ｍｓｇ＿ＩＤ”及び“Ｔｙｐｅ”を有するオリジナル入力メッセージに応答する応答メッセージを格納するために使用される。
【００８１】
ＤＩＡＲｅｇｉｓｔｅｒｉｎｇの場合、“Ｔｒｕｅ（真）”は、メッセージ送信者がＤＩＡＲｅｇｉｓｔｅｒｉｎｇメッセージを処理した後にＤＩＡ記述を受け取ることに同意することを示し、ＤＩＡＴｒａｎｓｍｉｔｔｉｎｇの場合、“Ｔｒｕｅ（真）”は、メッセージ送信者がＤＩＡ記述の受け取りに成功したことを示し、ＤＩＡＵｐｄａｔｉｎｇの場合、“Ｔｒｕｅ（真）”は、メッセージ送信者が更新ＤＩＡ記述の受け取りに成功したことを示す。
【００８２】
“Ｆａｌｓｅ（誤り）”は、上記３つの場合において“同意しない”、”ＤＩＡ記述の受け取りにおいて不具合がある”、“更新ＤＩＡ記述の受け取りにおいて不具合がある”ことを示す。“Ｒｅｓｐｏｎｓｅ”要素が用いられたときには、“ＤＩＡＤｅｓｃｒｉｐｔｉｏｎ”は使用しない。
【００８３】
問題を解決するための別の手段が、標準的な方法におけるネゴシエーションメカニズムに関するより高いレベルのＤＩＡメッセージによって提供される。
【００８４】
本発明は、特定の実施形態について説明されてきたが、当業者にとっては他の多くの変形例、修正、他の利用が明らかである。それゆえ、本発明は、ここでの特定の開示に限定されず、添付の請求の範囲によってのみ限定され得る。
【００８５】
なお、本出願は日本国特許出願、特願２００２−２０４２８６号（２００２年７月１２日提出）に関連し、それらの内容は参照することにより本文中に組み入れられる。
【図面の簡単な説明】
【００８６】
【図１】ＤＩＡネゴシエーションを有するマルチメディア分散ネットワークを示す図である。
【図２】ディスカバリ問合せＸＭＬメッセージの例を示す図である。
【図３】更新ＤＩＡの例を有するディスカバリ応答ＸＭＬメッセージを示す図である。
【図４】ネゴシエーションのためのＭＰＥＧ−２１汎用ＤＩＡメッセージ・レイヤを示す図である。
【図５】ピア間のＭＰＥＧ−２１汎用ＤＩＡネゴシエーションメッセージ・フローチャートを示す図である。
【図６】ＤＩＡ記述ネゴシエーションメッセージ・スキーマのシンタックス及びセマンティクスのブロック図である。
【符号の説明】
【００８７】
４．１ ＭＰＥＧ−２１ ＤＩＡ記述
４．２ ＤＩＡネゴシエーションレイヤ
４．３ ピア・ツー・ピア通信レイヤ
４．４ ネットワーク・トランスポート・レイヤ
４．５ ＤＩＡ登録メッセージ、ＤＩＡ伝送メッセージ、ＤＩＡ更新メッセージ【Technical field】
[0001]
The present invention relates to digital item adaptation, and more particularly to MPEG-21 digital item adaptation (DIA) that requires negotiation between different MPEG-21 peers.
[Background Art]
[0002]
DIA is a newly defined MPEG-21 part for specifying a description / tool for adaptation of digital items (Digital Items). The focus is on "terminals and networks", and the overall purpose of DIA is to interoperate with advanced multimedia content by isolating users from deployment, management and implementation issues related to networks and terminals. -To achieve transparent access. This allows users to generate and share multimedia content, always with agreed / contracted quality, reliability and flexibility, and to allow multimedia applications to connect to different sets of users. Network and terminal resources can be provided as needed to form a community.
[0003]
The current DIA description includes user characteristics (User Characteristics), terminal performance (Terminal Capabilities), network characteristics (Network Characteristics), and natural environment characteristics (Natural Environmental Characteristics) A tool and a usage environment (Usage Environment) description tool that specifies a tool for describing a BSD (Bitstream Syntax Description Language) description are defined. All of these descriptions are tools required for configuring Digital Items on the client or server side.
[0004]
In order to implement content adaptation, transmission and negotiation of the DIA description between peers is strongly required to be defined in an interoperable manner. Negotiation mechanisms and protocols need to be defined to support the distribution of multimedia resources to different terminals. There are useful scenarios where data adaptation is required, such as one-way broadcasting applications to different terminals, interactive interactive applications for content adaptation, real-time streaming adaptation to different networks, etc. . There, DIA descriptions for terminals, networks, and user preferences must be exchanged and negotiated once they are required to do so. The DIA negotiation mechanism should be defined to transmit the DIA description in real time and to facilitate communication between peers such as terminals, servers, gateways, proxies, etc. to update the DIA description. By following the MPEG-21 DIA description and the set of MPEG-21 negotiation mechanisms defined here, a universal multimedia frame network can be set up, and content adaptation can be implemented in different multimedia terminals, networks and usage environments. Can be processed.
[0005]
The present invention is to solve the following problems.
DIA descriptions run on different physical machines with various operating systems and are exchanged, updated, and transmitted between multimedia terminals and peers operating in a changing security, application, and tool environment. However, negotiations are built on a high-level basis.
[0006]
Regardless of the network protocol used by the terminal and the peer, the negotiation of the DIA description between the peers is performed individually to achieve effective and continuous digital item adaptation.
[0007]
Digital items are dynamically adapted to different terminals, networks, and users by implementing a negotiation mechanism at both involved peers.
[Disclosure of Invention]
[Means for Solving the Problems]
[0008]
In a first aspect of the present invention, an advertisement meta-data is created using an MPEG-21DIA description and an XML schema that includes peer resolvers, peer discovery, channel bindings, and some other generic messages for endpoint routing. Provides a way to define the location of data. Based on the end-to-end peer connection, a high level protocol definition is used to exchange and update DIA description information using peer discovery.
[0009]
That is, a negotiation method for digital item adaptation (DIA) is provided. The method is based on a standardized DIA description schema for peers that are MPEG-21 compatible terminals and uses at least one of a usage environment description, an XDI (context digital item) description and a BSDL (bitstream syntax description language) description. Generating an MPEG-21 DIA description, including placing the DIA description in a predetermined location used for exchange, transmission or update in a negotiation protocol; and implementing a generic protocol message to implement the functionality of the generic protocol. -Includes the steps of identifying a schema and exchanging, updating or transmitting DIA descriptions using a defined protocol.
[0010]
The method includes the steps of identifying a flexible advertisement metadata description schema to describe various types of resources, including at least one of a peer, a peer domain, and a channel; Incorporating a DIA description. In this case, the method may further include an advertisement metadata description schema parser that interprets the advertisement metadata description.
[0011]
The method comprises the steps of establishing a connection for a peer that needs to exchange, transmit or update a DIA description in a peer domain by establishing a channel using a channel binding protocol; The method may include routing protocol messages using a protocol and mutually recognizing peers using a peer resolver protocol.
[0012]
The above method is based on a peer discovery protocol for querying and responding to advertisement metadata including a DIA description, exchanging and updating the DIA description by enabling the required discovery message infrastructure. Or transmitting.
[0013]
In the method of the first aspect above, the step of identifying a generic protocol message schema may include a message schema parse in all parsers included in all implemented protocols.
[0014]
According to a second aspect of the present invention, a general-purpose high-level storage for storing an MPEG-21DIA description for registering, transmitting and updating DIA description information based on a base network connection in accordance with various network protocols Define a DIA negotiation message.
[0015]
That is, the present invention provides a negotiation method for digital item adaptation (DIA). The method includes the steps of establishing a connection between peers that require DIA negotiation based on universal high-level peer-to-peer and real network protocols and that are MPEG-21 compatible terminals. Generating an MPEG-21 DIA description including at least one of a usage environment description, an XDI (context digital item) description, and a BSDL (bitstream syntax description language) description based on a standardized DIA description schema; Identifying a generic and mandatory DIA negotiation message schema including a DIA description and a DIADescription element to implement a negotiation mechanism; and DIA negotiation between peers requiring DIA negotiation. Registering, transmitting, or updating the DIA description in the communication message.
[0016]
The method includes defining the DIA description as a reference using "Reference" to indicate the entity of the DIA description located on the World Wide Web, or using "DIDescriptionDescription" under the DIADescription element. It may include the step of defining the DIA description as a message payload.
[0017]
The method comprises the steps of constructing a registration message for a first peer having a message ID of the first peer when the first peer wants to transmit or update the current DIA description to a second peer; Sending the message to the second peer, and sending a response message having the same message ID and the same message type and "response" information from the second peer to the first peer. It may further include. "Response" information includes "true" meaning that the second peer is ready to receive the DIA description from the first peer, and Contains "false" which means to refuse to receive
[0018]
The method comprises constructing a transmission message for a first peer having a message ID of a first peer and transmitting a current DIA description to a second peer; and transmitting the transmission message to the second peer. Sending to the peer and transmitting a response message having the same message ID and the same message type and "response" information from the second peer to the first peer may be further included. "Response" information is "true", meaning that the DIA description transmitted from the first peer to the second peer was successfully received, and transmitted from the first peer to the second peer for any reason. Contains "false", which means that the received DIA description has failed.
[0019]
The method comprises constructing an update message for a first peer having a message ID of a first peer and updating a current DIA description to a second peer, and transmitting the update message to the second peer. And sending a response message having the same message ID and the same message type from the second peer to the first peer, and "response" information. The "response" information includes "true", which means that the update of the DIA description from the first peer to the second peer has been successfully received, and, for any reason, the first peer to the second peer. Includes "false" which means that the receipt of the DIA description update has failed.
[0020]
In the method of the second aspect above, the step of identifying a generic and mandatory DIA negotiation message schema may include a DIA negotiation message schema parser on all peers involved in the DIA description exchange.
[0021]
Using the first means, based on the defined advertisement metadata XML schema, a user characteristic description, a terminal performance description, a network characteristic description, a natural environment characteristic description, an XDI description, and a BSDL description are defined and negotiated. It can be transmitted, exchanged or updated using protocols. This is described in more detail in Section 1 of the Detailed Description.
[0022]
Registering, transmitting or updating a user characteristic description, a terminal performance description, a network characteristic description, a natural environment characteristic description, an XDI description, and a BSDL description based on a defined general negotiation message by using a second means; Can be. This is discussed in more detail in Section 2.
[0023]
MPEG-21 peers are built by implementing high-level communication messages that conform to various network protocols. In addition, a message parser is required to be implemented at the peer.
[0024]
The present invention is to design a negotiation mechanism with defined messages used for content adaptation to various devices in the marketplace, and for all high level protocols for protocols that include defined advertisement metadata. By providing a generic message, a standardized method used in MPEG-21 digital item adaptation negotiation can be obtained.
BEST MODE FOR CARRYING OUT THE INVENTION
[0025]
FIG. 1 shows a conventional technique. The figure shows that the MPEG-21 DIA description (module 1.1) connects in networks (modules 1.5, 1.6, 1.7) ranging from wireless mobile phones and PDAs to PCs and servers / gateways / proxyes. It is necessary to transmit between the devices (modules 1.2, 1.3, 1.4).
[0026]
At present, there is no way for the module 1.7 digital media server to deliver the same content in the same format to different types of devices. Even if such devices could be connected in a peer-to-peer manner, they would not be able to connect to different types of devices due to their different capabilities and user preferences if there were no negotiation mechanisms defined. It is still impossible to adapt the same content. This limits content adaptation to a small area of the media access application.
[0027]
1. Negotiation of DIA description based on general-purpose protocol
This section attempts to present a generic peer-to-peer negotiation protocol to effectively exchange DIA descriptions required to adapt content to terminals under specific network conditions and user preferences. . This protocol should fit well with current and future networking protocols being developed.
[0028]
It should be noted that the automatic / manual configuration of the client-side DIA description is not an item that needs to be described in the present invention. For example, a CDI (Content Digital Item) session can be reconstructed with the associated XDI (Context Digital Item) received for session mobility in the manner described in this invention. However, when the XDI description is entered in the DIA negotiation metadata based on the protocol defined in the present invention, the XDI request and XDI transfer between the terminal and the server
Is practical and can implement session mobility for digital items.
[0029]
Here is a brief description of some terms (the peer concept can also be used in section 3.6.2).
[0030]
Peer: A peer is a networked device that implements a protocol. Each peer operates asynchronously independently of all other peers. Some peers may have more dependencies than others due to special relationships (gateways or routers). Peers can discover each other on the network to form a peer domain. Peers may advertise resources to other peers. A peer endpoint is a URI that uniquely identifies a peer network interface. Peer endpoints are used by peers to establish a direct peer-to-peer connection between two peers. A peer may need to use one or more relay peers to send a message to another peer. Each peer is uniquely identified by a unique peer ID.
[0031]
Peer domain: A peer domain is a collection of peers that have some common problem. Also, the peer domain can be statically predefined. Peers self-organize into peer domains. Each peer domain is also identified by a unique peer domain ID. The protocol describes how peers publish, discover, associate and monitor peer domains.
Channel: A channel is a virtual communication pipe used to send and receive messages between services or applications through endpoints. The channel provides the network abstract through the peer endpoint transport. A peer endpoint corresponds to an available peer network interface that can be used to send and receive data to and from another peer. The channel provides single peer location and illusion of virtual in and out mailboxes independent of network topology. Channels can provide a point-to-point mode of communication.
[0032]
Messages: Information transmitted using channels and between endpoints is packaged as messages. The protocol is specified as a set of XML messages exchanged between peers. The use of XML messages to define a protocol allows many different types of peers to participate in the protocol. Each peer is free to implement the protocol in the way that best suits its capabilities and roles.
Advertisement metadata: All resources such as peers, peer domains, channels and services are represented by advertisement metadata.
[0033]
Advertisement metadata: All resources such as peers, peer domains, channels and services are represented by advertisement metadata.
[0034]
DIA metadata: All digital item adaptation descriptions, such as usage environment description, BSDL description, XDI (the only DIA description wrapped in DID), along with MPEG-7 media description, advertised main metadata Represented by DIA metadata in the description.
[0035]
ID: Within the defined protocol there are a number of entities (peers, peer domains, pipes and content) that need to be uniquely identifiable. The ID uniquely identifies an entity and serves as a standard way to refer to that entity. URIs are used as expressions of IDs.
[0036]
The negotiation protocol defined in MPEG-21 consists of a set of open protocols and is intended for peer-to-peer communication in which DIA metadata is transferred at a peer over a public network in a general manner. . Peers defined in the protocol allow peers to interact directly with other peers and resources, even when some of them are behind a firewall or on a different network transport Create a virtual network. The defined protocol should meet interoperability requirements, which means that interconnected peers must easily communicate with each other between different systems and communities. Also, peer-to-peer networks should support different programming languages, operating systems and networking platforms implemented on top of TCP / IP, HTTP, Bluetooth, Home PNA, and many other protocols. is there. It should also be able to support the widest range of digital devices, including CEs, PDAs, appliances, network routers, PCs, servers and storage systems, etc.
[0037]
Protocols are a set of mechanisms specifically designed for peer-to-peer network computing. With these mechanisms, peers can work together to form self-organizing and self-configuring peer domains without relying on locations in the network and without the need for a centralized management infrastructure.
[0038]
Peers advertise their DIA metadata and use protocols to discover available network resources (services, channels, etc.) from other peers. Peers form and combine peer domains to create special relationships. Multiple peers work together to send a message allowing full peer connectivity. All protocols allow peers to communicate without having to understand or manage potentially complex and dynamic network topologies. The protocol allows peers to dynamically route messages over any number of network hops to any destination in the network. Each message carries a complete or partially ordered list of gateway peers through which the message can be routed. If the route information is incorrect, the intermediate peer can help find a new route dynamically.
[0039]
Protocols are multiple mechanisms that work together to allow discovery, organization, monitoring, and communication between peers. They are,
[0040]
A mechanism that allows a peer to send a query to one or more peers and receive a response (or multiple responses) to the query. It implements a query / response protocol. The response message corresponds to the inquiry via a unique ID included in the message body. When a peer is discovered, a query can be sent to that peer.
[0041]
A mechanism that allows peers to advertise their own resources and discover resources from other peers (peer domains, channels and additional peers). All peer resources are described and advertised using advertisement metadata. Metadata is represented as an XML document.
[0042]
A mechanism that allows a peer to establish a virtual communication channel between one or more peers. Channels provide the underlying communication mechanism between peers.
[0043]
A mechanism that allows a peer to discover the routes used to send messages to another peer. If Peer A wants to send a message to Peer C and there is no direct route between Peer A and Peer C, Peer A finds a relay peer to send a message to Peer C There is a need.
[0044]
All of these protocols are implemented using a common messaging layer.
[0045]
1.1 XML Schema Based Message for Protocol
Peer resolver: A peer resolver allows the delivery of generic queries to one or more handlers in a domain and matches them to the response. Each query is addressed to a specific handler name. This handler name defines specific semantics for the query and its response, but is not associated with a specific peer. A query may be received by multiple peers in a domain and may be processed according to the handler name if such a handler name is defined at that peer. The intent of the peer resolver is to provide the required general purpose query / response infrastructure for building high-level resolver services. In many situations, higher level services may be better aware of the domain topology.
[0046]

[0047]
HandlerName (handler name): A string that specifies how to handle this query.
ScrPeerID: ID of the peer that issued the inquiry.
QueryID: Inquiry ID. The real ID should be included in the response to this inquiry.
Query: Query structure.
[0048]

[0049]
HandlerName: defines how to handle the response.
QueryID: ID of the query to which this responds.
Response: Response structure
[0050]
Endpoint Routing: The connection of the defined protocols of the network can be transient and the message routing is non-deterministic. Endpoint routing here defines a set of request / query messages that are processed by the routing service to support peer route messages to its destination. When a peer is asked to send a message to a given peer endpoint address, if it has a route to this peer, the peer consults its local cache. If no route is found, it sends a route resolver query message to its available peer route router for route information. Peer routers provide the ability to cache route information and bridge different physical or logical networks. When the peer router receives the route query, it knows the destination and answers the query by returning the route information as a list of hops. The message can be sent to a first router, and the router uses the route information to route the message to a destination peer. At any point, the route information becomes useless and requires the current router to find a new route. The endpoint router defined here is intended to supply the necessary hooks to the user defined routing service to manipulate and update routes. Two communicating peers need to use a peer router to send messages depending on their network location. Peer routers generally cache route information. Peers can query peer routers for route information. Peers in a peer domain can be peer routers.
[0051]

[0052]
DestPeerID: ID of the destination peer.
Cached: true if the response can be a cached response; false if the response must not come from the cache.
[0053]

[0054]
DestPeerID: ID of the destination peer.
RoutPeerID: The peer ID of the router that knows the route to the destination peer.
AdvMetadata: Advertisement metadata of the routing peer.
GatewayID: Sequence ID of the gateway.
[0055]
Channel Binding: Channel binding is used by applications and services to communicate with other peers. A channel is a virtual channel between two endpoints. Channel binding can use various transport protocols, such as HTTP, TCP / IP or TLS transport. Channels can be viewed as abstract named message queues and support operations of create, open / resolve (bind), close (unbind), delete, send, and receive. Multiple binding inquiry messages may be sent. One or more responses may be received. A response need not be received.
[0056]

[0057]
ChannelID: Channel ID to be resolved.
Cached: True if the response can be a cached response. False if the answer must not originate from a cache. The requester may require that information not be retrieved from the cache. This is to get the latest information from the peer to address the old connection.
PeerID: A peer ID is assigned. Identify the peer ID of only the peer for which a response is expected. Responses from all other peers are ignored. This does not guarantee that the response to the channel binding request will be made by the peer.
[0058]

[0059]
ChannelID: Channel ID to be resolved.
Found: Used to indicate whether the input channel was found at the specified peer.
PeerAdvMetadata: The advertisement metadata of the peer whose input channel was revealed.
[0060]
Peer Discovery: Peer discovery is used to discover published peer resources and also advertise their own resources. Resources are represented as advertisement metadata. Peer discovery allows peers to discover metadata in their domain. The intent is to provide a basic discovery infrastructure for building high-level discovery services. In many situations, the discovery information is better known by higher-level services, as the services may have better knowledge of the domain topology. Peer discovery basically provides a basic mechanism for discovering advertisement metadata, while at the same time providing hooks so that such high-level services and applications can participate in the discovery process.
[0061]

[0062]
Number: Specifies the maximum number of responding peer advertisement metadata.
Attribute and Value: Only metadata including name attribute and value elements can be detected.
PeerAdvMetadata: Advertisement metadata of the requesting peer.
Update: Indicates that the DIA description transferred in PeerAdvMetadata is just an updated description (true) or a complete description (false).
[0063]

[0064]
Number: Specifies the number of received response elements.
Attribute and Value: Reflects a response to a Discovery Query.
PeerAdvMetadata: Advertisement metadata of the responding peer.
Update: Indicates that the transferred DIA description in PeerAdvMetadata is just an updated description (true) or a complete description (false).
Response: Response structure
[0065]
1.2 XML schema-based metadata
The advertisement metadata provided in the XML schema is used to describe peers, peer domains, channels, media resources, services and many other types of resources. The DIA description intended to supply the information needed to adapt a Media Resource is placed here in the advertisement metadata. The defined protocol is defined according to such key information and is used to pass such metadata between peers.
[0066]
The advertisement, metadata, description, schema and their semantics are shown below.
[0067]

[0068]
Name: This is an optional string that can be associated with a peer, peer domain, channel. Names do not need to be unique unless obtained from a centralized naming service that guarantees the uniqueness of the name.
PeerID: This is an element that uniquely identifies a peer.
PeerDomainID: This element provides a Peer Domain ID. Each peer domain has a unique ID.
ChannelID: This is an element for uniquely specifying a channel (Channel).
Description: This is an optional element of any type that can be used to provide detailed DIA description and metadata.
Service: This element describes the association between the domain service indicated by its class and any parameters specified. Further, the service section may optionally include an element indicating that the service is unavailable. This element is used to communicate the configuration choices made by the owner of the peer.
[0069]
Finally, FIGS. 2 and 3 show examples of DiscoveryQuery (Discovery Query) and DiscoveryResponse (Discovery Response) XML messages in the case of DIA description update, respectively. The mobile phone client and digital multimedia server in the Internet of FIG. 1 know each other, and via a wired and wireless network, a peer resolver, an endpoint router, and a channel binding. (Channel Binding) by setting up a valid connection between them by sending a message. The server sends a Peer Discovery message to all mobile phones that match the "attribute" and "value" and responds with their DIA update response, for example, the DIA shown in FIG. Attempt to get display "element update".
[0070]
2. Generic DIA negotiation message between distributed peers using XML schema
DIA negotiation as defined in MPEG-21 is intended for peer-to-peer transfer of DIA metadata over a general network in a generic way. Open network platforms can be designed for peer-to-peer computing. A set of open protocols that enables peer-to-peer communication and cooperation by connected devices on networks ranging from mobile phones and wireless PDAs to PCs and servers / gateways / proxyes, For example, section 1 Peer Resolver, Endpoint Routing, Peer Discovery, and Channel Binding may be defined. Another solution to DIA description negotiation, in an interoperable manner, is to define a higher level generic DIA description negotiation message that stores DIA description and metadata. The advertisement metadata defined in section 1.2 does not need to hold the DIA description and metadata. All of these negotiation messages can be designed on top layers of a defined generic protocol and / or on the normally existing lowest layer physical network protocols such as HTTP / TCP / IP. This concept is shown in FIG.
[0071]
Module 4.1 includes Usage Environment (XDI), Context Digital Item (BSDI), BSDL (Context Digital Item), which can be accessed by the URI or stored as a payload (DIADescriptionData) in the negotiation message. This is a DIA description including a bitstream syntax description language (Bitstream Syntax Description Language). Modules 4.2, 4.3, 4.4 are separate layers for the messages for DIA negotiation, the protocol for peer-to-peer communication, and the negotiation mechanism that defines the physical network transport, respectively. Module 4.5 provides three generic messages (DIARegister, DIATransmit, and DIAUpdate) that store the highest layer module 4.1 DIA description for DIA negotiation. FIG. 5 shows a flowchart of the negotiation message.
[0072]
Module 5.1 shows the generated MPEG-21 DIA description for Peer A, including usage environment, XDI (Context Digital Item), BSDL (Bitstream Syntax Description Language) description, based on the standardized DIA description schema.
[0073]
Module 5.2 indicates that peer A constructs a registration (or transmission, update) message when peer A wants to transmit or update the current DIA description to peer B. The registration message is used to request registration of a DIA description from one peer to another peer. Transmission messages are used to send detailed terminal specifications for communication between peers. The update message is used when one terminal information of one peer is changed to notify the change of the terminal information from one peer to another peer.
[0074]
Module 5.3 indicates that Peer A sends a registration (or transmission, update) message to Peer B with the DIA description for Peer A.
[0075]
Module 5.4 indicates that Peer B constructs a response message for registration (or transmission, update) with "response" information to Peer A.
[0076]
Module 5.5 indicates that peer B returns a response message for registration (or transmission, update) with "response" information to peer A.
[0077]
Peer A checks the value contained in the "Response" information in the response message to see if the DIA description negotiation between Peer A and Peer B was successful, and sends this to module 5.6. Show. If the value of the "response" information is "true", then as shown in module 5.7, it means that peer B accepts the registration from peer A and updates or updates the new DIA description of peer A. Indicates that it is ready to receive a DIA description from peer A for any of the descriptions. Also, if the value of the "response" information is "false", it is desired that picture B refuse to register from peer A and receive a DIA description from peer A, as shown in module 5.8. Indicates that there is no or a problem with receiving a new or updated DIA description.
[0078]
The syntax and semantics of the DIA description negotiation message schema shown in FIG. 6 are shown below.
[0079]

[0080]
Type: Indicates a DIA negotiation message type such as "DIARegistering", "DIATransmitting", and "DIAUpdating".
DIARegistering: The message type used to register the DIA description when the peer attempts to transmit or update the current DIA description.
DIATransmitting: The message type used to carry the current peer DIA description.
DIAUpdating: The message type used to update the current peer DIA description.
Msg_ID: Message identifier defined by the message sender. All messages sent in response to a message must include the identifier of the original message.
SenderPeer_ID: Indicates the peer ID of the sender of the message.
RecipientPeer_ID: Indicates the peer ID of the intended recipient of the message.
DIADescription: All digital item adaptation descriptions that need to be transmitted, exchanged or updated, such as usage environment description, BSDL description, XDI (DIA description for session mobility wrapped in DID). The DIADescription can be included in the message as the payload "DIADescriptionData" or the "Reference" can be used to specify the entity of the DIA description to be located on the World Wide Web.
Response: Used to store a response message in response to the original input message having the same “Msg_ID” and “Type”.
[0081]
In the case of DIARegistering, "True" indicates that the message sender agrees to receive the DIA description after processing the DIARegistering message, and in the case of DIATransmitting, "True" indicates that the message sender In the case of DIAUpdating, "True (true)" indicates that the message sender has successfully received the updated DIA description.
[0082]
“False (error)” indicates that “disagree”, “there is a problem in receiving the DIA description”, and “there is a problem in receiving the updated DIA description” in the above three cases. When the “Response” element is used, “DIADescription” is not used.
[0083]
Another means to solve the problem is provided by higher level DIA messages regarding the negotiation mechanism in a standard way.
[0084]
Although the present invention has been described with respect to particular embodiments, many other variations, modifications, and other uses will become apparent to those skilled in the art. Therefore, the present invention is not limited to the specific disclosure herein, but only by the appended claims.
[0085]
This application is related to Japanese Patent Application No. 2002-204286 (filed on Jul. 12, 2002), the contents of which are incorporated herein by reference.
[Brief description of the drawings]
[0086]
FIG. 1 illustrates a multimedia distributed network with DIA negotiation.
FIG. 2 is a diagram illustrating an example of a discovery inquiry XML message.
FIG. 3 is a diagram illustrating a discovery response XML message having an example of an update DIA.
FIG. 4 illustrates an MPEG-21 generic DIA message layer for negotiation.
FIG. 5 shows an MPEG-21 Generic DIA negotiation message flowchart between peers.
FIG. 6 is a block diagram of the syntax and semantics of a DIA description negotiation message schema.
[Explanation of symbols]
[0087]
4.1 MPEG-21 DIA description
4.2 DIA negotiation layer
4.3 Peer-to-peer communication layer
4.4 Network Transport Layer
4.5 DIA registration message, DIA transmission message, DIA update message

Claims (12)

A method for negotiating digital item adaptation (DIA), comprising:
Based on a standardized DIA description schema for a peer that is an MPEG-21 compatible terminal, an MPEG- containing at least one of a usage environment description, an XDI (context digital item) description and a BSDL (bitstream syntax description language) description. Generating a 21 DIA description;
Placing the DIA description in a predetermined location used for exchange, transmission or update in a negotiation protocol;
Identifying a generic protocol message schema to implement the generic protocol functionality;
Exchanging, updating, or transmitting said DIA description using said protocol. Identifying and defining a flexible advertisement metadata description schema to describe various types of resources, including at least one of peers, peer domains and channels;
Incorporating the DIA description into the advertisement metadata;
The method of claim 1, further comprising: The method of claim 2, further comprising the step of implementing an advertisement metadata description schema parser at the peer that interprets the advertisement metadata description. Establishing a connection for the peer that needs to exchange, transmit or update the DIA description in the peer domain by establishing a channel using a channel binding protocol;
Routing the protocol message using an endpoint routing protocol;
Mutually recognizing said peers using a peer resolver protocol. Exchange, update, or update the DIA description by enabling the required discovery message infrastructure based on a peer discovery protocol for querying and responding to advertisement metadata including the DIA description The method of claim 1, further comprising the step of transmitting. The method of claim 1 or 5, wherein identifying the generic protocol message schema further comprises implementing message schema parsing on all parsers included in all implementing protocols. A method for negotiating digital item adaptation (DIA), comprising:
Establishing a connection between peers that require DIA negotiation based on generic high-level peer-to-peer and real network protocols and are MPEG-21 compatible terminals;
An MPEG-21 DIA description including at least one of a usage environment description, an XDI (context digital item) description, and a BSDL (bitstream syntax description language) description is generated based on a standardized DIA description schema for the peer. Steps to
Identifying a generic and mandatory DIA negotiation message schema that includes the DIA description and a DIADescription element to implement a negotiation mechanism;
Registering, transmitting, or updating the DIA description in a DIA negotiation message between peers requiring DIA negotiation. Defining the DIA description as a reference using "Reference" to indicate the entity of the DIA description located on the World Wide Web, or as the message payload using "DIADescriptionData" under the DIADescription element The method of claim 7, including the step of defining a DIA description. Constructing a registration message for the first peer having the message ID of the first peer when the first peer wants to transmit or update the current DIA description to the second peer;
Sending the registration message to the second peer;
Sending a response message having the same message ID and the same message type from the second peer to the first peer, and "response"information;
The "response" information may be "true", meaning that the second peer is ready to receive a DIA description from the first peer, and the second peer may send the first response to the first peer for any reason. The method of claim 7, comprising "false" meaning to refuse to receive the DIA description from another peer. Constructing a transmission message for the first peer having the message ID of the first peer and transmitting the current DIA description to the second peer;
Sending the transmission message to the second peer;
Transmitting a response message having the same message ID and the same message type from the second peer to the first peer, and "Response"information;
The "response" information includes "true", which means that the DIA description transmitted from the first peer to the second peer was successfully received, and the first peer from the first peer for any reason. 8. The method of claim 7, including "false" meaning that the receipt of the DIA description transmitted to the two peers failed. Constructing an update message for the first peer having the message ID of the first peer and updating the current DIA description to the second peer;
Sending the update message to the second peer;
Transmitting a response message having the same message ID and the same message type from the second peer to the first peer, and "Response"information;
The "response" information includes "true", which means that the update of the DIA description from the first peer to the second peer was successful, and the first peer for any reason. The method of claim 7, comprising "false" meaning that the receipt of the DIA description update to the second peer failed. 12. The method of any of claims 7 to 11, wherein the step of identifying and defining the generic and mandatory DIA negotiation message schema further comprises a DIA negotiation message schema parser for all peers involved in the DIA description exchange. The method according to one.

Images