インターネットプロトコルテレビ（ＩＰＴＶ）のダウンストリームユーザのための制御可能なマルチキャスト管理方法
本発明は、ＩＰＴＶダウンストリームユーザのための制御可能なマルチキャスト管理方法を提供することにより、ネットワークにアクセスするユーザの静的管理に基づくものである現在のマルチキャストサービス制御管理に伴う主要な欠点を実質的に解決する。本発明の方法は以下を含む。ユーザによって開始されるＤＨＣＰ要求がＳＴＢ端末によって受け取られ、ユーザ情報が、第１の関連情報の組として識別され、挿入される。ＤＳＬＡＭが、挿入された第１の関連情報の組を抽出し、次いでこれを、第２の関連情報の組と一緒にＯＳＳに送る。ＯＳＳは、第３の関連情報の組が、システムの現在の情報とマッチするかどうか判定する。マッチは、ユーザが、元のアカウント開始ノードにおいて正常にアクセスしていることを示す。マッチしない場合、ユーザがローミングユーザであるかどうか判定される。ローミングユーザである場合、ユーザの情報リストが更新される。ローミングユーザでない場合、ユーザは、拒絶される。ユーザリストが更新され、マルチキャスト許可制御リストが更新される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰＴＶ（ＩＰベースのテレビ）、広帯域ベアラネットワーク領域、特に、ＰＣ（パーソナルコンピュータ）、ＳＴＢ（セットトップボックス）、ブラウザユーザ、および順序付きテレビチャネルに関する構築方法のためのものである。
【背景技術】
【０００２】
ＩＰＴＶサービスが台頭するにつれて、ネットワーク運用者およびコンテンツ提供者らは、ＩＰネットワークでサポートされ、有効性の高いマルチキャスト伝送と公正なマルチキャストアドレス分配を実行するロバストなマルチキャスト関連の定義を必要とすることに加え、効果的なユーザ管理制御機能のみならずマルチキャストサービスも開発し、運用しなければならない。それらは、例えば、どのようにしてマルチキャストサービスを生成するか、どのようにしてマルチキャストデータソースの配信およびユーザエントリを制御するか、どの方法を用いてそれらを検証するか、どのようにしてユーザに課金するか、誰がユーザのサインオンを検証するか、どのようにして料金を計算するか、使用されるべきプランが簡単、確実、かつ公正であることをどのようにして保証するか、ネットワークが安全かつスムーズであるようにするためにマルチキャストサービスフローをどのようにして監視し、制御するか、どのようにしてユーザがアプリケーションを終了するか、サービス割り込みとリソース回復などである。
【０００３】
現在のネットワークは、マルチキャストサービスの開始後に有効なマルチキャストサービスの管理と監視が行われなければ、非常に影響を受けやすいものとなり得る。また、ハッカーもこれを利用して攻撃を行い、運用者はユーザに期待されるマルチキャストサービス品質を提供することができなくなる。以上の理由で、運用者も設備製造者も、マルチキャスト運用モデル、要件、および主要設備の状況などの情報をはっきりと認識する必要がある。
【０００４】
現在のマルチキャストサービスの制御管理は、主に、ユーザのネットワークへのアクセスの静的管理に基づくものである。例えば、番号を割り振るときには、ユーザ名とＡＤＳＬポートおよびＰＶＣ（専用仮想チャネル）との静的バインディングが実行される。この方法により、ユーザのマルチキャスト許可の程度を制御することができるが、常に固定されたネットワーク位置にあるユーザ端末に基づくものであるため、同時に、ローミングサービスの起動をある一定の限度に制限する。このユーザがローミングすると、すべての制御管理情報が有効でなくなる。
【０００５】
以下の図１において、ユーザローミングなしの、現在のマルチキャストユーザ制御プロセスを考察する。
【０００６】
図１には、運用者の元の９７／２０００システム（統合サービス処理システム）、ＩＰＴＶシステムオペレーティングシステムサポート（ＯＳＳ）、ＩＰ通信システムネットワーク管理システム（ＮＭＳ）、ＩＰコアネットワーク、メディア局、広帯域アクセスサーバ（ＢＲＡＳ／Ｌ３）、広帯域アクセス設備（ＤＳＬＡＭ／Ｌ２）、および端末装置（ＳＴＢ、ＴＶ、またはＰＣ）が含まれる。
【０００７】
ＩＰＴＶシステムＳＴＢユーザのための制御可能なマルチキャストサービスフローパスは、以下の通りである。
【０００８】
ステップ１−ＳＴＢユーザがアカウントを開くプロセスの間に、９７／２０００システムは、ユーザのＵＳＥＲＩＤ（ユーザ識別番号）、ＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ ＰＯＲＴおよびＰＶＣ情報をバインドしてＮＭＳに送り、ユーザ情報の特定の伝送フォーマットが、運用者の運用保守システムの状況に基づいて設定され得る。ＩＰＴＶと９７／２０００システムの間に、さしあたり特定のインターフェースがない場合には、情報バインディングとＮＭＳへの送信は、ＩＰＴＶ ＯＳＳを介して行われ得る。
【０００９】
ステップ２−ＳＴＢユーザが、ＯＳＳ上で必要とするチャネルの組を発注する。
【００１０】
ステップ３−ＯＳＳが、認証や料金徴収といったサービス発注操作を実行する。
【００１１】
ステップ４−ユーザが要求しているチャネルに基づき、ＯＳＳが、デバイス間プロトコルを介してＮＭＳに、ＵＳＥＲ ＮＡＭＥと、対応するマルチキャストグループの対応するマルチキャストグループ情報を送る（注：チャネルとマルチキャストグループが事前に照合され、対応付けられる場合には、これらは、システムＣＨＡＮＮＥＬ ＬＩＳＴに統合され、記載される）。
【００１２】
ステップ５−ＮＭＳサーバは、事前構成されるユーザ情報リストに基づいて、リスト上のマルチキャストグループ許可情報を更新し、同時に、マルチキャストグループ番号、ＡＤＳＬ ＰＯＲＴ、およびＰＶＣ情報を、対応するＤＳＬＡＭに渡す。
【００１３】
ステップ６−ＤＳＬＡＭは、リアルタイムで、マルチキャスト許可制御リストを更新し、操作結果をＮＭＳシステムに返す。
【００１４】
ステップ７−ＯＳＳは、ＮＭＳシステムフィードバックを正常に受け取ると、ユーザサービス注文がＯＫであることを指示し、ＣＨＡＮＮＥＬ ＬＩＳＴがＳＴＢに送られる。
【００１５】
ステップ８−ＳＴＢがＣＨＡＮＮＥＬ ＬＩＳＴを受け取った後、ローカルＬＩＳＴが更新され、ユーザが放送ＬＩＳＴからＣＨＡＮＮＥＬを選択するのを待つ間に、ＳＴＢは、対応するマルチキャストグループへの参加を求める要求を開始する。すなわち、要求マルチキャストグループのＩＧＭＰ ＲＥＰＯＲＴテキスト（ここでは一例としてチャネル２が使用されている）が送られる。
【００１６】
ステップ９−ＤＳＬＡＭは、ＩＧＭＰ ＲＥＰＯＲＴテキストを、ＡＤＳＬ ＰＯＲＴおよびＰＶＣと照合し、ユーザが要求されたマルチキャストグループに合法的に参加することができるかどうか判定するために、制御可能なマルチキャストリストで照会を実行する。参加できない場合には、ＤＳＬＡＭは、ユーザ要求テキストに影響を及ぼさない。
【００１７】
情報がマッチする場合、ＤＳＬＡＭは、要求を受け入れ、ユーザのエントリを処理する間に、このマルチキャストグループ内にこのユーザと同じユーザがいるかどうか判定する。同じユーザがいる場合、マルチキャストグループ番号とＤＳＬＡＭポートが、マルチキャスト送信リストに加えられ、その後のマルチキャストテキストが、この対応するリストを介して直接送信される。
【００１８】
マッチしない場合、ＤＳＬＡＭは、新しいマルチキャストグループに問い合わせる。
【００１９】
ステップ１０−ＳＴＢユーザが正常に参加した後、ＩＰＴＶによって送られているチャネル２マルチキャストフローは、ＤＳＬＡＭによってポート１と３に直接コピーされてよく、このグループ内のＳＴＢユーザは、チャネル２の番組を正常に受信することができ、ポート２ユーザは、チャネル２を受信することができない。
【００２０】
前述のプログラムでは、アカウントが開かれた後、ユーザのマルチキャスト制御情報が静的にバインドされることが分かる。このモデルは、ＳＴＢとＰＣが移動され得ないサービス運用モデルに基づくものである。しかしながら、ＩＰＴＶサービス開発の動向は、ＳＴＢを、家庭電化製品と同様に店舗で自由に購入することができるというものである。ユーザは、ただ運用者にスマートカードを申し込み、ＩＰＴＶサービスを楽しむためにＳＴＢを挿入するだけでよい。ユーザは、当然ながら、このカードを、友人宅に行くときに、または旅行時に携帯し、ＩＰＴＶサービスを楽しむこともできる。この種のユーザがローミングを行うときには、ユーザ情報の静的バインディングは、明らかに、要件を満たすことができない。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明の目的は、前述の問題を解決するために、ローミングＩＰＴＶユーザの制御可能なマルチキャスト管理方法を提供することである。
【課題を解決するための手段】
【００２２】
従来の制御可能なマルチキャスト方法と比べて、本発明は、ローミングユーザの制御可能なマルチキャスト管理を、ユーザ情報をＳＴＢによって開始されるＤＨＣＰ要求テキストで搬送し、次いで、これをＤＳＬＡＭが抽出し、ＯＳＳに送り、ＯＳＳと照合することによって実現する。具体的には、図２に示すように、以下の３つのステップが加えられている。
【００２３】
ステップ１−ＳＴＢユーザがＤＨＣＰ（これは業界で知られており、説明を要さない）要求を開始するときに、ＳＴＢ端末ソフトウェアが発見テキストにＵＳＥＲＩＤ情報を挿入する。
【００２４】
ステップ２−ＤＳＬＡＭがＤＨＣＰディスカバリテキストを抽出し、ＵＳＥＲＩＤ情報を取得し、次いで、その報告を、ユーザのＡＤＳＬ ＰＯＲＴおよびＰＶＣと一緒にＯＳＳに送る。
【００２５】
ステップ３−ＯＳＳは、ユーザの広帯域アクセス情報がシステムの現在の情報とマッチするかどうか判定する（広帯域アクセス情報にはＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ ＰＯＲＴ、およびＰＶＣＩＤが含まれる。これは、ユーザがアカウントを開いたときに、運用者によって事前構成される情報である）。
【００２６】
マッチは、ユーザが、元のアカウント開始ノードにおいて正常にアクセスしていることを示す。
【００２７】
マッチしない場合には、ユーザがローミングユーザであるかどうか判定される。
【００２８】
ローミングユーザである場合、ＮＭＳに、ユーザの情報リストを更新するよう通知される。
【００２９】
ローミングユーザでない場合、これは、非ローミングユーザが、無許可の領域からアクセスしていること、またはユーザがシステムに不正にアクセスしようとしていることを意味する。システムはこのユーザにタグ付けし、ユーザは、パスワード検証を開始すると拒絶される。
【００３０】
ステップ４−ＮＭＳは、ユーザリストを更新し、ＤＳＬＡＭに、マルチキャスト許可制御リストを更新するよう通知する。
【００３１】
ステップ５−ユーザは、サービスを正常に使用し、ローミングの場所において新しいサービスを発注することができる。
【００３２】
この方法は、余分なハードウェアの追加を不要にし、ＩＰシステムにとっての運用保守およびサービスをより容易にするため、ＳＴＢユーザのローミングサービスをはるかに使い易いものにする。
【発明を実施するための最良の形態】
【００３３】
本発明は、制御可能なマルチキャストをサポートするのみならず、ローミングユーザのための制御可能なマルチキャストもサポートし、運用サービスを拡張し、カード型分離式ＳＴＢモデルなどの互換性のあるアフターマーケット機器を追加することを容易にする。具体的な伝送プロセスについては、図３と以下の詳細な説明を参照されたい。
【００３４】
ＩＰＴＶシステムＳＴＢローミングの制御可能なマルチキャスト：
図３には、本発明に関与する装置間のインターフェースフローパスが示されており、ＩＰＴＶローミングユーザの検証プロセス全体と、配信および処理での主要パラメータが提示されている。この図には、以下が含まれる。
【００３５】
１． ９７／２０００がＯＳＳに、すべてのユーザがローミング許可を有するかどうか通知する。
【００３６】
２． ＳＴＢが、ＤＨＣＰ要求を開始し、ＯＰＴＩＯＮ６０でＵｓｅｒＩＤを取得する。
【００３７】
３． ＤＳＬＡＭが要求を代行受信して取り込み、ＯＳＳにユーザポート情報を送る。
【００３８】
４． ＯＳＳは、ユーザがローミングユーザであるかどうか判定し、ローミングユーザである場合、ユーザのマルチキャスト許可情報をＮＭＳに送る。
【００３９】
５． ＮＭＳは、ＤＳＬＡＭ／Ｌ２にマルチキャスト許可情報を送ると同時に、マルチキャスト許可制御リストを更新する。
【００４０】
６． ＳＴＢがマルチキャストグループへの参加を求める要求を開始する。
【００４１】
７． ＳＴＢがストリーミングメディアデータを正常に受信する。
【００４２】
上記のプロセスでは、ステップ２、３および４が、以前の制御可能なマルチキャストとは異なる本発明の部分である。これら３つの新しいステップを加えることによって、上記プロセスは、ＩＰＴＶローミングユーザ情報がリアルタイムでサブミットされ、決定され、ローミングユーザ許可の通知がリアルタイムで送信される機能を実現している。このようにして、ローミングユーザマルチキャスト許可制御の目的が達成される。
【図面の簡単な説明】
【００４３】
【図１】現在のマルチキャストユーザ制御フローパスを示す図である。
【図２】本発明におけるマルチキャストユーザ制御を示すブロック図である。
【図３】本発明におけるマルチキャストユーザ制御を示す流れ図である。
【技術分野】
【０００１】
本発明は、ＩＰＴＶ（ＩＰベースのテレビ）、広帯域ベアラネットワーク領域、特に、ＰＣ（パーソナルコンピュータ）、ＳＴＢ（セットトップボックス）、ブラウザユーザ、および順序付きテレビチャネルに関する構築方法のためのものである。
【背景技術】
【０００２】
ＩＰＴＶサービスが台頭するにつれて、ネットワーク運用者およびコンテンツ提供者らは、ＩＰネットワークでサポートされ、有効性の高いマルチキャスト伝送と公正なマルチキャストアドレス分配を実行するロバストなマルチキャスト関連の定義を必要とすることに加え、効果的なユーザ管理制御機能のみならずマルチキャストサービスも開発し、運用しなければならない。それらは、例えば、どのようにしてマルチキャストサービスを生成するか、どのようにしてマルチキャストデータソースの配信およびユーザエントリを制御するか、どの方法を用いてそれらを検証するか、どのようにしてユーザに課金するか、誰がユーザのサインオンを検証するか、どのようにして料金を計算するか、使用されるべきプランが簡単、確実、かつ公正であることをどのようにして保証するか、ネットワークが安全かつスムーズであるようにするためにマルチキャストサービスフローをどのようにして監視し、制御するか、どのようにしてユーザがアプリケーションを終了するか、サービス割り込みとリソース回復などである。
【０００３】
現在のネットワークは、マルチキャストサービスの開始後に有効なマルチキャストサービスの管理と監視が行われなければ、非常に影響を受けやすいものとなり得る。また、ハッカーもこれを利用して攻撃を行い、運用者はユーザに期待されるマルチキャストサービス品質を提供することができなくなる。以上の理由で、運用者も設備製造者も、マルチキャスト運用モデル、要件、および主要設備の状況などの情報をはっきりと認識する必要がある。
【０００４】
現在のマルチキャストサービスの制御管理は、主に、ユーザのネットワークへのアクセスの静的管理に基づくものである。例えば、番号を割り振るときには、ユーザ名とＡＤＳＬポートおよびＰＶＣ（専用仮想チャネル）との静的バインディングが実行される。この方法により、ユーザのマルチキャスト許可の程度を制御することができるが、常に固定されたネットワーク位置にあるユーザ端末に基づくものであるため、同時に、ローミングサービスの起動をある一定の限度に制限する。このユーザがローミングすると、すべての制御管理情報が有効でなくなる。
【０００５】
以下の図１において、ユーザローミングなしの、現在のマルチキャストユーザ制御プロセスを考察する。
【０００６】
図１には、運用者の元の９７／２０００システム（統合サービス処理システム）、ＩＰＴＶシステムオペレーティングシステムサポート（ＯＳＳ）、ＩＰ通信システムネットワーク管理システム（ＮＭＳ）、ＩＰコアネットワーク、メディア局、広帯域アクセスサーバ（ＢＲＡＳ／Ｌ３）、広帯域アクセス設備（ＤＳＬＡＭ／Ｌ２）、および端末装置（ＳＴＢ、ＴＶ、またはＰＣ）が含まれる。
【０００７】
ＩＰＴＶシステムＳＴＢユーザのための制御可能なマルチキャストサービスフローパスは、以下の通りである。
【０００８】
ステップ１−ＳＴＢユーザがアカウントを開くプロセスの間に、９７／２０００システムは、ユーザのＵＳＥＲＩＤ（ユーザ識別番号）、ＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ ＰＯＲＴおよびＰＶＣ情報をバインドしてＮＭＳに送り、ユーザ情報の特定の伝送フォーマットが、運用者の運用保守システムの状況に基づいて設定され得る。ＩＰＴＶと９７／２０００システムの間に、さしあたり特定のインターフェースがない場合には、情報バインディングとＮＭＳへの送信は、ＩＰＴＶ ＯＳＳを介して行われ得る。
【０００９】
ステップ２−ＳＴＢユーザが、ＯＳＳ上で必要とするチャネルの組を発注する。
【００１０】
ステップ３−ＯＳＳが、認証や料金徴収といったサービス発注操作を実行する。
【００１１】
ステップ４−ユーザが要求しているチャネルに基づき、ＯＳＳが、デバイス間プロトコルを介してＮＭＳに、ＵＳＥＲ ＮＡＭＥと、対応するマルチキャストグループの対応するマルチキャストグループ情報を送る（注：チャネルとマルチキャストグループが事前に照合され、対応付けられる場合には、これらは、システムＣＨＡＮＮＥＬ ＬＩＳＴに統合され、記載される）。
【００１２】
ステップ５−ＮＭＳサーバは、事前構成されるユーザ情報リストに基づいて、リスト上のマルチキャストグループ許可情報を更新し、同時に、マルチキャストグループ番号、ＡＤＳＬ ＰＯＲＴ、およびＰＶＣ情報を、対応するＤＳＬＡＭに渡す。
【００１３】
ステップ６−ＤＳＬＡＭは、リアルタイムで、マルチキャスト許可制御リストを更新し、操作結果をＮＭＳシステムに返す。
【００１４】
ステップ７−ＯＳＳは、ＮＭＳシステムフィードバックを正常に受け取ると、ユーザサービス注文がＯＫであることを指示し、ＣＨＡＮＮＥＬ ＬＩＳＴがＳＴＢに送られる。
【００１５】
ステップ８−ＳＴＢがＣＨＡＮＮＥＬ ＬＩＳＴを受け取った後、ローカルＬＩＳＴが更新され、ユーザが放送ＬＩＳＴからＣＨＡＮＮＥＬを選択するのを待つ間に、ＳＴＢは、対応するマルチキャストグループへの参加を求める要求を開始する。すなわち、要求マルチキャストグループのＩＧＭＰ ＲＥＰＯＲＴテキスト（ここでは一例としてチャネル２が使用されている）が送られる。
【００１６】
ステップ９−ＤＳＬＡＭは、ＩＧＭＰ ＲＥＰＯＲＴテキストを、ＡＤＳＬ ＰＯＲＴおよびＰＶＣと照合し、ユーザが要求されたマルチキャストグループに合法的に参加することができるかどうか判定するために、制御可能なマルチキャストリストで照会を実行する。参加できない場合には、ＤＳＬＡＭは、ユーザ要求テキストに影響を及ぼさない。
【００１７】
情報がマッチする場合、ＤＳＬＡＭは、要求を受け入れ、ユーザのエントリを処理する間に、このマルチキャストグループ内にこのユーザと同じユーザがいるかどうか判定する。同じユーザがいる場合、マルチキャストグループ番号とＤＳＬＡＭポートが、マルチキャスト送信リストに加えられ、その後のマルチキャストテキストが、この対応するリストを介して直接送信される。
【００１８】
マッチしない場合、ＤＳＬＡＭは、新しいマルチキャストグループに問い合わせる。
【００１９】
ステップ１０−ＳＴＢユーザが正常に参加した後、ＩＰＴＶによって送られているチャネル２マルチキャストフローは、ＤＳＬＡＭによってポート１と３に直接コピーされてよく、このグループ内のＳＴＢユーザは、チャネル２の番組を正常に受信することができ、ポート２ユーザは、チャネル２を受信することができない。
【００２０】
前述のプログラムでは、アカウントが開かれた後、ユーザのマルチキャスト制御情報が静的にバインドされることが分かる。このモデルは、ＳＴＢとＰＣが移動され得ないサービス運用モデルに基づくものである。しかしながら、ＩＰＴＶサービス開発の動向は、ＳＴＢを、家庭電化製品と同様に店舗で自由に購入することができるというものである。ユーザは、ただ運用者にスマートカードを申し込み、ＩＰＴＶサービスを楽しむためにＳＴＢを挿入するだけでよい。ユーザは、当然ながら、このカードを、友人宅に行くときに、または旅行時に携帯し、ＩＰＴＶサービスを楽しむこともできる。この種のユーザがローミングを行うときには、ユーザ情報の静的バインディングは、明らかに、要件を満たすことができない。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明の目的は、前述の問題を解決するために、ローミングＩＰＴＶユーザの制御可能なマルチキャスト管理方法を提供することである。
【課題を解決するための手段】
【００２２】
従来の制御可能なマルチキャスト方法と比べて、本発明は、ローミングユーザの制御可能なマルチキャスト管理を、ユーザ情報をＳＴＢによって開始されるＤＨＣＰ要求テキストで搬送し、次いで、これをＤＳＬＡＭが抽出し、ＯＳＳに送り、ＯＳＳと照合することによって実現する。具体的には、図２に示すように、以下の３つのステップが加えられている。
【００２３】
ステップ１−ＳＴＢユーザがＤＨＣＰ（これは業界で知られており、説明を要さない）要求を開始するときに、ＳＴＢ端末ソフトウェアが発見テキストにＵＳＥＲＩＤ情報を挿入する。
【００２４】
ステップ２−ＤＳＬＡＭがＤＨＣＰディスカバリテキストを抽出し、ＵＳＥＲＩＤ情報を取得し、次いで、その報告を、ユーザのＡＤＳＬ ＰＯＲＴおよびＰＶＣと一緒にＯＳＳに送る。
【００２５】
ステップ３−ＯＳＳは、ユーザの広帯域アクセス情報がシステムの現在の情報とマッチするかどうか判定する（広帯域アクセス情報にはＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ ＰＯＲＴ、およびＰＶＣＩＤが含まれる。これは、ユーザがアカウントを開いたときに、運用者によって事前構成される情報である）。
【００２６】
マッチは、ユーザが、元のアカウント開始ノードにおいて正常にアクセスしていることを示す。
【００２７】
マッチしない場合には、ユーザがローミングユーザであるかどうか判定される。
【００２８】
ローミングユーザである場合、ＮＭＳに、ユーザの情報リストを更新するよう通知される。
【００２９】
ローミングユーザでない場合、これは、非ローミングユーザが、無許可の領域からアクセスしていること、またはユーザがシステムに不正にアクセスしようとしていることを意味する。システムはこのユーザにタグ付けし、ユーザは、パスワード検証を開始すると拒絶される。
【００３０】
ステップ４−ＮＭＳは、ユーザリストを更新し、ＤＳＬＡＭに、マルチキャスト許可制御リストを更新するよう通知する。
【００３１】
ステップ５−ユーザは、サービスを正常に使用し、ローミングの場所において新しいサービスを発注することができる。
【００３２】
この方法は、余分なハードウェアの追加を不要にし、ＩＰシステムにとっての運用保守およびサービスをより容易にするため、ＳＴＢユーザのローミングサービスをはるかに使い易いものにする。
【発明を実施するための最良の形態】
【００３３】
本発明は、制御可能なマルチキャストをサポートするのみならず、ローミングユーザのための制御可能なマルチキャストもサポートし、運用サービスを拡張し、カード型分離式ＳＴＢモデルなどの互換性のあるアフターマーケット機器を追加することを容易にする。具体的な伝送プロセスについては、図３と以下の詳細な説明を参照されたい。
【００３４】
ＩＰＴＶシステムＳＴＢローミングの制御可能なマルチキャスト：
図３には、本発明に関与する装置間のインターフェースフローパスが示されており、ＩＰＴＶローミングユーザの検証プロセス全体と、配信および処理での主要パラメータが提示されている。この図には、以下が含まれる。
【００３５】
１． ９７／２０００がＯＳＳに、すべてのユーザがローミング許可を有するかどうか通知する。
【００３６】
２． ＳＴＢが、ＤＨＣＰ要求を開始し、ＯＰＴＩＯＮ６０でＵｓｅｒＩＤを取得する。
【００３７】
３． ＤＳＬＡＭが要求を代行受信して取り込み、ＯＳＳにユーザポート情報を送る。
【００３８】
４． ＯＳＳは、ユーザがローミングユーザであるかどうか判定し、ローミングユーザである場合、ユーザのマルチキャスト許可情報をＮＭＳに送る。
【００３９】
５． ＮＭＳは、ＤＳＬＡＭ／Ｌ２にマルチキャスト許可情報を送ると同時に、マルチキャスト許可制御リストを更新する。
【００４０】
６． ＳＴＢがマルチキャストグループへの参加を求める要求を開始する。
【００４１】
７． ＳＴＢがストリーミングメディアデータを正常に受信する。
【００４２】
上記のプロセスでは、ステップ２、３および４が、以前の制御可能なマルチキャストとは異なる本発明の部分である。これら３つの新しいステップを加えることによって、上記プロセスは、ＩＰＴＶローミングユーザ情報がリアルタイムでサブミットされ、決定され、ローミングユーザ許可の通知がリアルタイムで送信される機能を実現している。このようにして、ローミングユーザマルチキャスト許可制御の目的が達成される。
【図面の簡単な説明】
【００４３】
【図１】現在のマルチキャストユーザ制御フローパスを示す図である。
【図２】本発明におけるマルチキャストユーザ制御を示すブロック図である。
【図３】本発明におけるマルチキャストユーザ制御を示す流れ図である。
【特許請求の範囲】
【請求項１】
ＩＰＴＶローミングユーザの制御可能なマルチキャスト管理方法であって、
１．前記ユーザによって開始されるＤＨＣＰ要求がＳＴＢ端末によって受け取られ、ユーザ情報が、第１の関連情報の組として識別され、挿入されるステップ、
２．ＤＳＬＡＭが挿入された前記第１の関連情報の組を抽出し、次いで、前記第１の関連情報の組を、第２の関連情報の組と一緒にＯＳＳに送るステップ、
３．前記ＯＳＳが、第３の関連情報の組が、システムの現在の情報とマッチするかどうか判定し、
マッチは、前記ユーザが、元のアカウント開始ノードにおいて正常にアクセスしていることを示し、
マッチしない場合、前記ユーザがローミングユーザであるかどうか判定され、
ローミングユーザでない場合、前記ユーザが拒絶され、
ローミングユーザである場合、前記ユーザの情報リストが更新されるステップ、および
４．マルチキャスト許可制御リストが更新されるステップ
を含む方法。
【請求項２】
前記第１の関連情報の組がディスカバリテキストである請求項１に記載の方法。
【請求項３】
前記第２の関連情報の組が、ユーザの対応するＡＤＳＬ ＰＯＲＴとＰＶＣを含む請求項１に記載の方法。
【請求項４】
前記第３の関連情報の組が広帯域アクセス情報を含む請求項１に記載の方法。
【請求項５】
前記広帯域アクセス情報が、ＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ，およびＰＶＣＩＤを含む請求項３に記載の方法。
【請求項６】
前記ユーザがローミングユーザであるかどうか判定されるときに前記ユーザ情報リストが更新されるステップが、前記ＮＭＳに、前記ユーザの情報リストを更新するよう通知するステップを含む請求項１に記載の方法。
【請求項７】
前記ユーザの情報リストが更新されるステップが、前記ＮＭＳ上の前記ユーザリストを更新するステップを含む請求項１に記載の方法。
【請求項８】
前記マルチキャスト許可制御リストが更新されるステップが、ＤＳＬＡＭ上のマルチキャスト許可制御リストを更新するステップを含む請求項１に記載の方法。
【請求項１】
ＩＰＴＶローミングユーザの制御可能なマルチキャスト管理方法であって、
１．前記ユーザによって開始されるＤＨＣＰ要求がＳＴＢ端末によって受け取られ、ユーザ情報が、第１の関連情報の組として識別され、挿入されるステップ、
２．ＤＳＬＡＭが挿入された前記第１の関連情報の組を抽出し、次いで、前記第１の関連情報の組を、第２の関連情報の組と一緒にＯＳＳに送るステップ、
３．前記ＯＳＳが、第３の関連情報の組が、システムの現在の情報とマッチするかどうか判定し、
マッチは、前記ユーザが、元のアカウント開始ノードにおいて正常にアクセスしていることを示し、
マッチしない場合、前記ユーザがローミングユーザであるかどうか判定され、
ローミングユーザでない場合、前記ユーザが拒絶され、
ローミングユーザである場合、前記ユーザの情報リストが更新されるステップ、および
４．マルチキャスト許可制御リストが更新されるステップ
を含む方法。
【請求項２】
前記第１の関連情報の組がディスカバリテキストである請求項１に記載の方法。
【請求項３】
前記第２の関連情報の組が、ユーザの対応するＡＤＳＬ ＰＯＲＴとＰＶＣを含む請求項１に記載の方法。
【請求項４】
前記第３の関連情報の組が広帯域アクセス情報を含む請求項１に記載の方法。
【請求項５】
前記広帯域アクセス情報が、ＤＳＬＡＭ ＩＤＥＮＴＩＦＹ、ＡＤＳＬ，およびＰＶＣＩＤを含む請求項３に記載の方法。
【請求項６】
前記ユーザがローミングユーザであるかどうか判定されるときに前記ユーザ情報リストが更新されるステップが、前記ＮＭＳに、前記ユーザの情報リストを更新するよう通知するステップを含む請求項１に記載の方法。
【請求項７】
前記ユーザの情報リストが更新されるステップが、前記ＮＭＳ上の前記ユーザリストを更新するステップを含む請求項１に記載の方法。
【請求項８】
前記マルチキャスト許可制御リストが更新されるステップが、ＤＳＬＡＭ上のマルチキャスト許可制御リストを更新するステップを含む請求項１に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００９−５０８３６５（Ｐ２００９−５０８３６５Ａ）
【公表日】平成２１年２月２６日（２００９．２．２６）
【国際特許分類】
【出願番号】特願２００８−５１５３６８（Ｐ２００８−５１５３６８）
【出願日】平成１８年６月８日（２００６．６．８）
【国際出願番号】ＰＣＴ／ＩＢ２００６／０５１８３３
【国際公開番号】ＷＯ２００６／１３１８９８
【国際公開日】平成１８年１２月１４日（２００６．１２．１４）
【出願人】（５０６１１７８１７）ユーティースターコム・テレコム・カンパニー・リミテッド (2)
【Ｆターム（参考）】
【公表日】平成２１年２月２６日（２００９．２．２６）
【国際特許分類】
【出願日】平成１８年６月８日（２００６．６．８）
【国際出願番号】ＰＣＴ／ＩＢ２００６／０５１８３３
【国際公開番号】ＷＯ２００６／１３１８９８
【国際公開日】平成１８年１２月１４日（２００６．１２．１４）
【出願人】（５０６１１７８１７）ユーティースターコム・テレコム・カンパニー・リミテッド (2)
【Ｆターム（参考）】
[ Back to top ]