JP2008289164A - モバイル通信においてブロードキャスト／マルチキャストサービスを提供する設備と方法 - Google Patents

Abstract

【課題】モバイル通信ネットワークにおいてブロードキャスト／マルチキャストサービスを提供する。モバイルネットワークにおけるＢＣＭＣＳデータ処理の低効率および動的なマルチキャスト放送処理の問題を解決する。
【解決手段】本発明による通信制御装置は、ネットワークインタフェースと、ネットワークインタフェースで新たなマルチキャスト通信フローを確立することを要求する要求情報を受信したとき、基地局との間にすでに確立されたその他のマルチキャスト通信フローの通信品質パラメータと新たなマルチキャスト通信フローの通信品質パラメータに基づき、新たなマルチキャスト通信フローが経由する基地局に対して新たなマルチキャスト通信フローを確立できるかどうかを判断し、新たなマルチキャスト通信フローが経由する基地局に対する判断の結果がＹＥＳである場合、新たなマルチキャスト通信フローを確立する制御部と、を有する。
【選択図】図７

Description

本発明は、モバイル通信ネットワークにおいてサービスを提供する設備と方法に関し、特にモバイル通信システムにおけるマルチキャスト処理サーバーに関する。ここで言うモバイル通信ネットワークとは、ブロードキャストとマルチキャストに対応するモバイル通信システムのことである。

３ＧＰＰ２は国際標準化団体であり、第三世代モバイル通信ネットワークのシステム構造と基準を開発することはその目標である。これらの基準はＣＤＭＡ２０００無線インタフェースのネットワークに適用される。３ＧＰＰ２団体において、ＣＤＭＡ２０００のブロードキャスト／マルチキャストサービス（ＢＣＭＣＳ）が提案された。ＢＣＭＣＳは単一ソースノードユーザから送信されるマルチメディアデータの一点対複数点の伝送に対応する。ＢＣＭＣＳの主な目的は、プロバイダのＣＤＭＡ２０００ネットワークシステムにおいて、１つまたは複数のモバイル端末にＢＣＭＣＳマルチメディアデータを伝送するとき、ＣＤＭＡ２０００の無線インタフェースリソースを最適に使用することにある。

図１は、３ＧＰＰ２団体が提案したＢＣＭＣＳシステム機能ノードの分布を示した概略図である。３ＧＰＰ２基準Ｘ．Ｓ００２２とＡ．Ｓ００１９に基づくＢＣＭＣＳパケットの転送メカニズムを図３に示す。各ＢＣＭＣＳフロー（１つのマルチキャストアドレスとポートに対応）にそれぞれ１つのＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤが割当てられる。アクセスネットワークにおいて、ＢＣＭＣＳデータフローは汎用ルーティングカプセル化（ＧＲＥ）トンネルにカプセル化されて伝送される。ＢＣＭＣＳデータフローとＧＲＥトンネルは厳格に一対一に対応付けられている。個々のＧＲＥトンネルにはそれぞれ１つのＧＲＥ識別子（ＧＲＥ ｋｅｙまたはＧＲＥ ＩＤ）がある。言い換えれば、ＢＣＭＣＳ通信システムにおいて、ＧＲＥ識別子、ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤとＢＣＭＣＳデータフローは厳格に一対一に対応付けられている。

図１において、ソースメディアフローはＢＣＭＣＳコンテンツ提供者１０４から送信される。ＢＣＭＣＳコンテンツ／アプリケーションサーバー６は、複数のＢＣＭＣＳコンテンツ提供者１０４から送信されたソースメディアフローを受信し、ソースメディアフローを処理した後、マルチキャストサービスノード（ｂｒｏａｄｃａｓｔ ｓｅｒｖｉｃｅ ｎｏｄｅ−ＢＳＮ）４を経由して、生成されたＢＣＭＣＳフローをＣＤＭＡ２０００無線アクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ−ＲＡＮ）に転送する。すべてのパケット制御ユニット５（Ｐａｃｋｅｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ−ＰＣＦ）と基地局／基地局コントローラ（ＢＳ／ＢＳＣ）設備９はいずれもＩＰマルチキャストパケットのコピーを生成し、それぞれ配信することができる。ＢＣＭＣＳコントローラ８はコアネットワークの設備であり、その機能としては、ＢＣＭＣＳセッションに関連する情報を管理し、パケットサービスノード３（Ｐａｃｋｅｔ Ｄａｔａ Ｓｅｒｖｉｎｇ Ｎｏｄｅ−ＰＤＳＮ）、マルチキャストサービスノード４、モバイル端末１０、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６に提供する。ＢＣＭＣＳコントローラ８はインタフェース１０２を介して認証・承認・課金サーバー（Ｓｅｒｖｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）１を経由してＢＣＭＣＳセッション関連の情報をパケットサービスノード３とマルチキャストサービスノード４に送信する。インタフェース１０３はモバイル端末１０に既存のＢＣＭＣＳセッション関連情報を提供することに用いられる。このインタフェースはＢＣＭＣＳ情報取得（ＢＣＭＣＳ ｉｎｆｏｒｍａｔｉｏｎ ａｃｑｕｉｓｉｔｉｏｎ）インタフェースとも呼ばれる。また、ＢＣＭＣＳコントローラ８はセキュリティーキーを生成し、モバイル端末１０に配布するなど、一部のセキュリティー機能も担当する。ＢＣＭＣＳコントローラ８はまたＢＣＭＣＳコンテンツ提供者１０４に対する認証を行い、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６にソースメディアフローを伝送するようＢＣＭＣＳコンテンツ提供者１０４を制御する。

図２は、ＢＣＭＣＳに基づくグループ通信システムアプリケーションの一例を示した図であり、ＰｏＣ（Ｐｕｓｈ ｔｏ ｔａｌｋ Ｏｖｅｒ Ｃｅｌｌｕｌａｒ）をグループアプリケーションとした例である。ＰｏＣにおいて、３つのグループがあるとする。セッション制御はセッションイニシエーションプロトコル（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ）に基づき、グループ内の管理はリアルタイムコントロールプロトコル（Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）により行われる。図２において、６はＢＣＭＣＳコンテンツ／アプリケーションサーバーであり、図１のＢＣＭＣＳコンテンツ／アプリケーションサーバー６およびＢＣＭＣＳコンテンツ提供者１０４に対応する機能を持つ。２はユニキャストパケットを制御するユニキャストパケット制御ユニットであり、７はセッション確立の機能を持つＳＩＰサーバーである。

図２には２つの独立のハニカムセル１０を担当する２つの基地局９がある。各グループには、それぞれ２つのグループモバイル端末１１がある。グループ内の１つのモバイル端末１１が話している場合、それはユニキャストデータフローをモバイル通信ネットワークの上りリンクを経由してＢＣＭＣＳコンテンツ／アプリケーションサーバー６に送信する。モバイル端末１１からのデータフローを受信したとき、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６はまずセッション情報をチェックし、その後、対応のコンテンツをマルチキャストによりモバイル通信ネットワークに送信する。マルチキャストパケットはマルチキャストサービスノード４によりキャプチャーされ、カプセル化されてモバイルネットワークのアクセスネットワークに転送される。パケット制御ユニット５と基地局／基地局コントローラ９により処理されて、グループに対応するＩＰマルチキャストフローはＢＣＭＣＳデータフローに変換され、その後、無線インタフェースのＢＣＭＣＳチャンネルに送信される。グループ内のモバイル端末１１はそのグループに対応する無線インタフェースチャンネルをモニタリングすれば、そのグループ内のデータを受信することができる。従って、ＢＣＭＣＳによりグループサービスをサポートすることにより、モバイル通信ネットワーク内の無線インタフェースリソースを大いに節約することができる。

図３は、図２の例におけるＢＣＭＣＳデータ転送の流れを示した図である。３つのグループが存在する場合、３つのマルチキャストデータフローがＢＣＭＣＳコンテンツ／アプリケーションサーバー６によりモバイル通信ネットワークに送信される。アクセスネットワークにおいて、対応的に３つのＢＣＭＣＳデータフローがある。ＢＣＭＣＳデータフローはＧＲＥトンネル１３にカプセル化される。ＢＣＭＣＳデータフローとＧＲＥトンネルは一対一に対応付けられている。

基地局／基地局コントローラ９において、無線インタフェースリソースのリザーブはＧＲＥトンネルに基づいて行われる。本例では、ある基地局が１９２ｋｂｐｓのＢＣＭＣＳ流量しかサポートできなく、且つ３つのＢＣＭＣＳデータフローをサポートする必要がある場合、各ＢＣＭＣＳデータフローの流量は６４ｋｂｐｓ以下でなければならない。ＰｏＣの場合、あるグループ内に話すメンバーがいなければ、伝送するデータもない。すべてのグループ通信グループにはいずれも話すメンバーがいないとき、リザーブされた無線インタフェースリソースは無駄になる。

また、現在基地局で最大１２８ｋｂｐｓのＢＣＭＣＳ速度しかサポートできなく、かつ、各グループ通信グループの帯域が最小８０ｋｂｐｓである場合（Ｇ．７１１音声コードを使用する場合）、基地局コントローラ（ＢＳＣ）９は３つのグループ通信グループに無線インタフェースリソースを割当てることができなく、１つのＢＣＭＣＳデータフロー（１つのグループ通信グループに対応）だけに無線インタフェースリソースを割当てることができる。また、複数のＧＲＥトンネルが複数のＢＣＭＣＳデータフローに対応する場合、基地局／基地局コントローラ９は対応的に複数のデータバッファリングキューを生成して管理し、多くの複雑な操作をしてすべてのＧＲＥトンネルとバッファリングキューを管理する必要がある。これによって、ＢＣＭＣＳデータの伝送を遅延させ、グループ通信の性能に影響を与えることがある。グループ通信という遅延に敏感であるアプリケーションにとって、その影響が大きいと考えられる。

図４は、マルチキャストデータフローのＩＰパケットの形式を示した図である。これは標準的なＩＰマルチキャストパケットである。送信元アドレス１２１はＢＣＭＣＳコンテンツ／アプリケーションサーバー６のＩＰアドレスであり、送信先アドレス１２２はグループ通信グループに割当てられたマルチキャストアドレスである。マルチキャストＩＰの純負荷１２３でセッションのデータを伝送している。ＢＣＭＣＳデータフローのパケット形式はＩＰマルチキャストデータフローのそれと同様である。

図５は、アクセスネットワークにおけるＧＲＥトンネルのＩＰパケット形式を示した図である。ＧＲＥトンネルは汎用のカプセル化の方法である。ＧＲＥパケットヘッダの開始部分は一部のＧＲＥデータフィールドであり、あるプロトコルとポリシーの格納に用いられる。ＧＲＥ識別子（ＧＲＥ ＩＤ）１３６は、ＧＲＥトンネルの識別子であり、あるアクセスネットワークのカバーエリア内に唯一に割当てられる。マルチキャストパケットはマルチキャストパケットＩＰ１２２内にカプセル化される。

図６は、ＰｏＣサービスにおける代表的なデータフローの状況を示した図である。ここには、グループ内に話すメンバーがいなければ、グループ内にデータの伝送がないという非常に重要な特徴がある。この場合、グループサービスに割当てられた無線インタフェースリソースが完全に無駄になる。３ＧＰＰ２団体において、マルチキャストノードサーバーは関連基地局のＢＣＭＣＳリソースの使用状況を把握できないため、簡単なＢＣＭＣＳフレームの転送しか行えなく、さらなる分析とスケジューリングを行うことができない。

本発明は、モバイルネットワークにおけるＢＣＭＣＳデータ処理の低効率およびモバイル端末の使用状況に基づく動的なマルチキャスト放送処理ができない問題を解決するために、通信制御装置と方法を提供する。

本発明は、ネットワークインタフェースを経由してアプリケーションサーバーとリンクし、さらに複数の基地局を経由して複数の端末とリンクする通信制御装置を提供する。この通信制御装置は、
前記アプリケーションサーバーから情報を受信し、前記基地局との間に確立されたマルチキャスト通信フローを利用して、前記情報を前記基地局に送信するネットワークインタフェースと、
前記ネットワークインタフェースで新たなマルチキャスト通信フローを確立することを要求する要求情報を受信したとき、前記基地局との間にすでに確立されたその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、前記新たなマルチキャスト通信フローが経由する基地局に対して新たなマルチキャスト通信フローを確立できるかどうかを判断し、前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立する制御部と、を有する。

本発明は、アプリケーションサーバーから情報を受信し、複数の基地局との間に確立されたマルチキャスト通信フローを利用して、前記情報を前記基地局に送信する通背印制御方法を提供する。この通信制御方法は、
アプリケーションサーバーから新たなマルチキャスト通信フローを確立することを要求する要求情報を受信する受信ステップと、
前記基地局との間にすでに確立されたその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、前記新たなマルチキャスト通信フローが経由する基地局に対して新たなマルチキャスト通信フローを確立できるかどうかを判断する判断ステップと、
前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立するマルチキャスト通信フロー確立ステップと、を含む。

本発明は下記の効果がある。
（１）アクセスネットワークのゲートウェーで関連の基地局におけるＢＣＭＣＳリソースの使用状況を知ることができるので、セッションに基づくスケジューリングと分析機能をサポートすることができる。
（２）ＧＲＥトンネルにおいてカプセル化されたすべてのＢＣＭＣＳデータフローは、すべてのＢＣＭＣＳリソースを十分利用することができる。
（３）有効な転送スケジューリングにより、ＣＤＭＡ２０００モバイル通信システムは、同様な無線インタフェースリソースを使用してより多くのＢＣＭＣＳデータフローをサポートすることができる。
（４）複数のＢＣＭＣＳデータフローを１つのＧＲＥトンネルに入れる場合、ＢＣＭＣＳデータフローの数が増加しても、複数の基地局での変動を行う必要がない。
（５）基地局で複数のＢＣＭＣＳデータフローのために複数のバッファリングキューを生成する必要がないので、基地局のマルチキャストデータ処理遅延を効果的に低減させることができる
（６）モバイル端末とＢＣＭＣＳデータサーバーには変更を行う必要は一切ないので、アプリケーション層に影響は全くない。

本発明をＣＤＭＡ２０００ １ｘＥＶＤＯ ＢＣＭＣＳ通信システムを例に説明する。本発明は、その他のモバイル通信ネットワークのマルチキャスト放送サービスに適用することができる。

図７は、本発明で提案したマルチキャスト処理サーバーを使用したＢＣＭＣＳグループの実施例を示した図である。

図７のＰｏＣにおいて、３つのグループがあると想定する。図７において、１は認証・承認・課金サーバー、２はユニキャストパケットを制御するユニキャストパケット制御ユニット、３はパケットサービスノード、６はＢＣＭＣＳコンテンツ／アプリケーションサーバー、７はセッション確立の機能を持つＳＩＰサーバーである。

図７の実施例には２つの独立のハニカムセル１０を担当する２つの基地局９がある。各グループには、それぞれ２つのグループモバイル端末１１がある。

図２に比べて、本発明は、パケット制御ユニット５、マルチキャストサービスノード４、ＢＣＭＣＳコントローラ８の代わりにマルチキャスト処理サーバー１５を採用した。なお、ここではマルチキャスト処理サーバーを例にしているが、もちろんブロードキャスト処理サーバーの機能を含むこともできる。

図８は、図７に示した実施例における本発明の提案を適用したＢＣＭＣＳデータ転送の流れを示した図である。ここでは、複数のＢＣＭＣＳデータフローが１つのＧＲＥトンネル１６にカプセル化される。従って、１つのＧＲＥ識別子は複数のＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤに対応することができる。ここに複数ＧＲＥトンネルが存在する可能性を排除しない。本発明は、ＢＣＭＣＳ＿ＧＲＥ＿ＩＤをＧＲＥトンネル１６の識別子とすることを提案した。この識別子は、ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤの数字スペースにリザーブし、ＧＲＥトンネル１６にのみ使用される。従って、マルチキャスト処理サーバー１５でＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤ割当を行うとき、ある数字が予めＧＲＥトンネル用にリザーブされる。

図９は、アクセスネットワークにおいて本発明の提案を適用したＧＲＥトンネルのＩＰパケット形式を示した図である。これは図５のＧＲＥトンネルの形式とほぼ同様であるが、ＧＲＥ識別子フィールドの内容は特別にリザーブしたＢＣＭＣＳ＿ＧＲＥ＿ＩＤ １６６である。

図１０は、本発明に係るマルチキャスト処理サーバーの内部構造を示した図である。ネットワークインタフェースは、入力ラインインタフェース（ｉｎｐｕｔ ｌｉｎｅ ｉｎｔｅｒｆａｃｅ）２０と出力ラインインタフェース（ｏｕｔｐｕｔ ｌｉｎｅ ｉｎｔｅｒｆａｃｅ）２２を含む。また、ネットワークインタフェースは、入力ラインインタフェース２０と内部バス（ｉｎｔｅｒｎａｌ ｂｕｓ）１７が接続される受信バッファ（ｒｅｃｅｉｖｉｎｇ ｂｕｆｆｅｒ）２１と、出力ラインインタフェース２２と内部バス１７が接続される送信バッファ（Ｓｅｎｄｉｎｇ ｂｕｆｆｅｒＳ）２３とを含む。さらに、内部バス１７には少なくともプロセッサー（ｐｒｏｃｅｓｓｏｒ）１８、プログラムメモリ（ｐｒｏｇｒａｍ ｍｅｍｏｒｙ）１９およびデータメモリ（ｄａｔａ ｍｅｍｏｒｙ）２３が接続されている。プログラムメモリ１９にプロセッサー１８で実行する機能モジュールが記憶されており、少なくとも、パケット送受信モジュール１９２と、アクセスネットワーク内のＧＲＥトンネル関連の操作を処理するＧＲＥカプセル化／その他フレーミングモジュール（ＧＲＥ ｅｎｃａｐｓｕｌａｔｉｏｎ ａｎｄ ｆｒａｍｉｎｇ ｍｏｄｕｌｅｓ）１９３と、ＳＩＰユーザエージェントモジュール（ＳＩＰ ＵＡ ｍｏｄｕｌｅ）１９４と、シグナリングとセキュリティー機能モジュール（ｓｉｇｎａｌｉｎｇ ａｎｄ ｓｅｃｕｒｉｔｙ ｆｕｎｃｔｉｏｎ）１９５と、ＢＣＭＣＳコントローラモジュール（ＢＣＭＣＳ ｃｏｎｔｒｏｌｌｅｒ ｆｕｎｃｔｉｏｎ）１９６と、その他のモジュールを選択起動するための基本的な制御モジュール（ｂａｓｉｃ ｃｏｎｔｒｏｌ ｒｏｕｔｉｎｅ）１９１とを含む。

また、本発明はプログラムメモリ１９に汎用ルートカプセル化／マルチキャスト放送サービススケジューリングモジュール（ＧＲＥ／ＢＣＭＣＳ ｆｌｏｗ ｓｃｈｅｄｕｌｅｒ）１９８を有する。

そのＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は具体的に下記のことを行う。
１．ＢＣＭＣＳデータフロー要求メッセージを受信したとき、ＧＲＥトンネルとＢＣＭＣＳデータフロー間のマッピング関係を処理する。
２．ＧＲＥトンネルに新たなＢＣＭＣＳ＿ＧＲＥ＿ＩＤを割当てる。
３．基地局コントローラからＧＲＥトンネルと関連する使用可能リソース情報（例えば帯域制限）を収集する。
４．ＢＣＭＣＳデータフローのパラメータと基地局コントローラのリソース制限の状況によって、ＢＣＭＣＳデータフロースケジューリングを行う。
５．シグナリングインタフェースの保守を行ってＢＣＭＣＳデータフローを更新する。
６．ＧＲＥ／ＢＣＭＣＳフロー対応表の保守を行う。

また、マルチキャスト処理サーバーのデータメモリには、ＧＲＥ／ブロードキャストマルチキャストサービスフロー対応表（ＧＲＥ／ＢＣＭＣＳ ｆｌｏｗ ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ ｔａｂｌｅ）２３１をさらに有する。ここに格納している情報は、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュールでＢＣＭＣＳデータフローのスケジューリングを行う根拠になる。

基本制御モジュール１９１により制御され、受信バッファ２１に記憶されているマルチキャストＩＰパケットはパケット送受信モジュール１９２により順に読み込まれる。ＢＣＭＣＳコントローラモジュール１９６は、まず受信したマルチキャストＩＰパケットの送信元アドレスと送信先アドレスをチェックする。このマルチキャストＩＰパケットがすでに登録されたＢＣＭＣＳデータフローに該当しない場合、このパケットを廃棄する。その後、基本制御モジュール１９１は、このパケットをＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８に渡す。このモジュールは、パケットの内容に対してＧＲＥ／ＢＣＭＣＳフロー対応表２３１をチェックし、表の内容とローカルポリシーに基づきそのスケジューリングを行う。スケジューリングされたパケットは、ＧＲＥカプセル化／その他フレーミングモジュール１９３に渡されてＢＣＭＣＳ関連のカプセル化が行われる。最後に、基本制御モジュール１９１は、カプセル化されたＧＲＥパケットを送信バッファ２３に渡して送信する。ある場合（例えば、現在の基地局リソースが不足している場合）には、スケジューリングの結果によって、ＧＲＥパケットは、一時的にデータメモリ２３に記憶され、送信を待機することもある。

図１１は、本発明に係るＧＲＥ／ＢＣＭＣＳフロー対応表の代表的な構造を示した図である。２３１−１は基地局／基地局コントローラの識別子であり、２３１−２は対応のＩＰアドレスであり、２３１−３はＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュールにより割当てられたＢＣＭＣＳ＿ＧＲＥ＿ＩＤであり、２３１−４に帯域制限など基地局／基地局コントローラのリソースリザーブ情報が記憶されている。これらの情報は、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８による動的転送スケジューリングに非常に重要な意味がある。２３１−５はＢＣＭＣＳ＿ＧＲＥ＿ＩＤマルチキャストアドレス／ポートである。表において、データフローが２３１−６とセッション状態ｓｔａｔｕｓを記述する。２３１−７に各ＢＣＭＣＳデータフローの情報（例えば、開始／一時停止、１６秒後終了など）が格納されている。これらの情報はＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８による動的転送スケジューリングに非常に重要な意味がある。例えば、グループ通信の場合、グループ内に話すメンバーがいないとき、グループ内に伝送するデータもない。このとき、マルチキャスト処理サーバーは対応のグループのセッション情報２３１−７を更新する。これらの情報に基づき、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は対応のＢＣＭＣＳデータフローにリソースを割当てない。

ＯＭＡの定義によれば、各グループ通信の時間間隔は３０秒である。その他のグループプリケーションがデータの時間間隔に対して時間制限を行うこともある。類似の情報がＧＲＥ／ＢＣＭＣＳフロー対応表２３１に格納され、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、このような情報およびローカルのポリシーに基づき効果的にリソーススケジューリングを行うことができる。

また、表２３１には基地局／基地局コントローラアイテム２３１−９もある。個々の基地局／基地局コントローラアイテム２３１−９に複数のＢＣＭＣＳデータフローアイテム２３１−１０を付けることができる。各データフローアイテム２３１−１０はそれぞれその基地局／基地局コントローラが受信する必要がある１つのＢＣＭＣＳデータフローに対応する。

図１５は、本発明に係る静的ＢＣＭＣＳデータフロー確立のメッセージを示した図である。ここでは、静的とはフローリソースが予め通信双方により配分されたこと、動的とはフローリソースが予め配分されず、通信双方が動的に協議して決めたことをいう。

図１５において、本発明で触れたＳＩＰのマルチグループアプリケーションを想定した。

他のタイプのアプリケーションの場合、ネットワークプロバイダは、メッセージ１２０３と１２０３を対応のセッション確立メッセージプロセスに置き換えればよい。ステップ１２０１では、基地局／基地局コントローラは予めＢＣＭＣＳリソースをリザーブした。リソースを予めリザーブする方法が多くある。例えば、モバイルプロバイダは手動で静的にリザーブする必要があるリソースを配分することができる。なお、マルチキャスト処理サーバーはステップ１２０２においてＧＲＥ／ＢＣＭＣＳフローのマッピングを完成する必要がある。

ステップ１２０３では、モバイル端末は、ＩＮＶＩＴＥメッセージをＢＣＭＣＳコンテンツ／アプリケーションサーバー６に送信する。ＢＣＭＣＳコンテンツ／アプリケーションサーバー６は、ＩＮＶＩＴＥメッセージを受信した後、ステップ１２０４でＯＫ確認メッセージを送信し、マルチキャストアドレス／ポートを明示する。アプリケーションセッション確立プロセスが終了した後、アプリケーションサーバーはステップ１２０５においてマルチキャスト処理サーバーにＩＰマルチキャストフローを送信する。マルチキャストアドレスとポートは予め配置する必要がある。アプリケーションサーバーから送信されたＩＰマルチキャストパケットを受信したとき、マルチキャスト処理サーバーは、ＧＲＥ／ＢＣＭＣＳフローのスケジューリングを行う（ステップ１２０６）。その後、１２０７において、スケジューリングの結果に基づき、ＩＰパケットはカプセル化された後、ＧＲＥトンネルを経由して基地局／基地局コントローラに送信される。基地局／基地局コントローラは、受信したＧＲＥパケットデカプセルして、ＢＣＭＣＳ物理チャンネルを経由してモバイル端末に送信する。

図１２は、本発明に係る動的ＢＣＭＣＳデータフロー確立のメッセージを示した図である。図において、本発明で触れたＳＩＰのマルチグループプリケーションを想定した。

まず、ＢＣＭＣＳリソースは、静的ＢＣＭＣＳシステムのように予めリザーブすることができる。また、リソースのリザーブとしては１つ目のモバイル端末がＢＣＭＣＳサービスに登録開始しときにステップ１３０１を行うこともできる。モバイル端末はステップ１３０２においてアプリケーションセッションを起動する。この場合、アプリケーションサーバーは、マルチキャスト処理サーバー１５にＳＩＰ ＩＮＶＩＴＥメッセージ１３０３を送信する。このメッセージには、少なくともフロー記述とグループメンバー記述が含まれる。マルチキャスト処理サーバー１５はステップ１３０４においてＧＲＥ／ＢＣＭＣＳフローマッピングを行う。セッション実施中に、ある情報に変化が発生した場合、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６は、マルチキャスト処理サーバー１５にメッセージを送信して更新を行う（例えば、ＳＩＰｒｅ−ＩＮＶＩＴＥまたはＵｐｄａｔｅメッセージを使用）。

ステップ１３０４では、マルチキャスト処理サーバー１５は、メッセージ１３０３の内容とアクセスネットワークの状態によって汎用ルートカプセル化／ＢＣＭＣＳフローのマッピングを行う。その後、すべてのＢＣＭＣＳコンテンツ／アプリケーションサーバー６からのマルチキャストフローにＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤを割当てる。３ＧＰＰ２の定義によれば、ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤとマルチキャストアドレス／ポートは一対一に対応付けられている。これらの情報はステップ１３０６においてモバイル端末１１に知らせる。その後、３ＧＰＰ２のプロセスに従って、モバイル端末１１は動的ＢＣＭＣＳ登録（ステップ１３０８、１３０９、１３１０、１３１１）を発起する。ステップ１３１０において、基地局／基地局コントローラ９は、ＢＣＭＣＳ＿ＧＲＥ＿ＩＤをインタフェースを経由してモバイル端末１１に知らせる。

ＢＣＭＣＳ登録プロセスが終了した後、ステップ１３１２において、マルチキャスト処理サーバー１５は、ＩＧＭＰ ｊｏｉｎメッセージによりマルチキャストフローの受信を起動する。ＢＣＭＣＳコンテンツ／アプリケーションサーバー６からのマルチキャストフローを受信したとき、マルチキャスト処理サーバー１５はＧＲＥ／ＢＣＭＣＳフローのスケジューリングを行う（ステップ１３１３）。その後、ステップ１３１４において、スケジューリングの結果に基づき、ＩＰパケットはカプセル化され、ＧＲＥトンネルを経由して基地局／基地局コントローラ９に送信される。基地局／基地局コントローラ９は受信したＧＲＥパケットデカプセルして、ＢＣＭＣＳ物理チャンネルを経由してモバイル端末１１に送信する。

静的ＢＣＭＣＳの場合、マルチキャスト処理サーバー１５において行われるフローマッピングも予め設定する必要がある。

図１３は、本発明に係る、マルチキャスト処理サーバーの内部における動的データフローマッピング確立を示す代表的な流れ図である。マルチキャスト処理サーバー１５は、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６からのＳＩＰ ＩＮＶＩＴＥメッセージ１４０１を受信したとき、まずメッセージの内容をチェックする。そのメッセージは、少なくともフロー記述とグループメンバー記述を含む。そのＢＣＭＣＳデータフローの情報とＧＲＥ／ＢＣＭＣＳフロー対応表２３１のアイテムと矛盾する場合は、関連のリソースがすでに別のＢＣＭＣＳデータフローにより占用されたことを意味する。このとき、ＢＣＭＣＳコンテンツ／アプリケーションサーバー６に拒否メッセージ（本発明では、ＳＩＰ ４０６ ｕｎａｃｃｅｐｔａｂｌｅメッセージを使用）１４１０を送信する。

そのＢＣＭＣＳデータフローは、ＧＲＥ／ＢＣＭＣＳフロー対応表２３１にアイテムがない場合、対応の表中の基地局／基地局コントローラアイテムをチェックする（ステップ１４０３）。チェックした結果、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュールは帯域など、このＢＣＭＣＳデータフローをサポートする十分なリソースがないと発見すれば、アプリケーションサーバーに拒否メッセージ１４１０を送信する。そのＢＣＭＣＳサービスをサポートできないのは、グループ内部の一部のメンバーだけである場合もあるが、このとき、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は拒否メッセージ１４１０においてサポートできないメンバーを明示する（１４０９）。そのＢＣＭＣＳデータフローがサポートされている場合、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、それにＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤを割当て（１３０５）、ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤとＢＣＭＣＳ＿ＧＲＥ＿ＩＤ間のマッピングをする。その後、ステップ１４０７でＧＲＥ／ＢＣＭＣＳフロー対応表２３１を更新する。最後に成功メッセージ１４０８（本発明では、ＳＩＰ ２００ ＯＫメッセージを使用）をＢＣＭＣＳコンテンツ／アプリケーションサーバー６に送信する。このプロセスにおいて、ＢＣＭＣＳデータフローとＢＣＭＣＳ＿ＧＲＥ＿ＩＤのマッピング関係が確立された。

ステップ１４０４では、関連基地局のＢＣＭＣＳリソースの使用状況をチェックする。例えば、図１１に示すように、基地局１（ＡＮＩＤが０ｘ０４０１）に３つのＢＣＭＣＳフローがある。基地局のＩＰアドレスは１０．１０．１２．２２７である。その基地局はすでにＢＣＭＣＳサービスに一部の空ポートリソースをリザーブしており、１２８ｋｂｐｓのサービス流量を同時にサポートすることができる。なお、この３つのＢＣＭＣＳフローは、（１）ＰｏＣセッションのためのＢＣＭＣＳフロー（ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤ：０ｘ４００１；アドレス／ポート：２２５．０．０．１０／１００９３；フロー記述：３０ｋｂｐｓ、１秒当り５０パケット、１つの話し時間は多くても３０秒；セッション状態：休止）、（２）ＶｏＩＰ会議セッションのためのＢＣＭＣＳフロー（ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤ：０ｘ４００２；アドレス／ポート：２２５．０．０．１１／１００９３；フロー記述：２０ｋｂｐｓ、１秒当り５０パケット、静音検知機能有り；セッション状態：アクティブ）、（３）セッションダウンロードのためのＢＣＭＣＳフロー （ＢＣＭＣＳ＿ＦＬＯＷ＿ＩＤ：０ｘ４００３；アドレス／ポート：２２５．０．０．１２／１００９３；フロー記述：６４ｋｂｐｓ；セッション状態：アクティブ）を含む。

図１３に示した例のように、マルチキャストサーバーはその他のアプリケーションサーバーから送信されたＩＮＶＩＴＥメッセージ１４０１を受信した。例えば、このメッセージに新しいＰｏＣセッション（フロー記述：３０ｋｂｐｓ、１秒当り５０パケット、１つの話し時間は多くても３０秒）が含まれている。理論的に、基地局は、１２８ｋｂｐｓの帯域によりこれらのセッション（３０＋２０＋６４＋３０＝１４４ｋｂｐｓ）をサポートすることができない。このとき、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８はその基地局でこの新しいＰｏＣセッションをサポートできるかをチェックする。判断の根拠として複数のローカルポリシーがあることも考えられるが、ここでは例として最も簡単なポリシーを示す。セッションのダウンロードは遅延に敏感ではないので、無視することができる。ＶｏＩＰ会議セッションは静音の時に２ｋｂｐｓの流量しかない。ＰｏＣセッションは休止状態の時に流量がない。従って、統計学上で、ＶｏＩＰ会議セッションの実際流量を２０ｋｂｐｓ×９０％＝１８ｋｂｐｓ、ＰｏＣセッションの実際流量を３０ｋｂｐｓ×７０％＝２１ｋｂｐｓと推定することができる。従って、現在推定したリソース占用は３９ｋｂｐｓであるので、基地局は、この新しいセッションをサポートすることができる。すべてのセッションが同時にピーク流量状態において運用される場合、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、この基地局に対して効果的にスケジューリングを行うことができる。

図１４は、本発明に係る、マルチキャスト処理サーバー１５の内部におけるマルチキャストデータのスケジューリングを示した代表的な流れ図である。ＢＣＭＣＳコンテンツ／アプリケーションサーバー６からＩＰマルチキャストパケットを受信したとき（１５０１）、マルチキャスト処理サーバー１５中のＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、そのマルチキャストパケットがすでに登録したＢＣＭＣＳデータフローに該当するかをチェックする（１５０２）。そのパケットが無効である場合、それを捨てる（１５０３）。その後、得られた情報とローカルポリシーに基づき、関連の基地局／基地局コントローラ９の現在の状況を評価する（１５０４）。リソースが十分であれば、そのパケットをカプセル化して、直接アクセスネットワークに転送する。この場合、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、ＧＲＥ／ＢＣＭＣＳフロー対応表２３１中のマッピングをチェックし（１５０７）、ステップ１４０８において送信する。現在のリソースが不足の場合、ＧＲＥ／ＢＣＭＣＳフロースケジューリングモジュール１９８は、あるバッファとスケジューリングメカニズムによりそのＩＰマルチキャストパケットのスケジューリングを行う（１５０６）。その後、リソースの利用が可能になったとき、カプセル化したパケットをステップ１５０８においてアクセスネットワークに送信する。

モバイル通信ネットワークにおけるＢＣＭＣＳシステムの構造を示した図である。 ＢＣＭＣＳに基づくグループ通信システムアプリケーションの一例を示した図である。 図１に示した例におけるＢＣＭＣＳデータ転送の流れを示した図である。 マルチキャストデータフローのＩＰパケットの形式を示した図である。 アクセスネットワークにおけるＧＲＥトンネルのＩＰパケットの形式を示した図である。 ＰｏＣサービスにおける代表的なデータフローの状況を示した図である。 本発明で提案したマルチキャスト処理サーバーを使用したＢＣＭＣＳグループの実施例を示した図である。 図７に示した実施例における本発明の技術を適用したＢＣＭＣＳデータ転送の流れを示した図である。 アクセスネットワークにおいて本発明の技術を適用したＧＲＥトンネルのＩＰパケット形式を示した図である。 本発明に係るマルチキャスト処理サーバーの内部構造を示した図である。 本発明に係るＧＲＥ／ＢＣＭＣＳフロー対応表の代表的な構造を示した図である。 本発明に係る動的ＢＣＭＣＳデータフロー確立のメッセージを示した図である。 本発明に係るマルチキャスト処理サーバーの内部に確立した動的データフローマッピングの代表的な流れを示した図である。 本発明に係るマルチキャスト処理サーバーの内部におけるマルチキャストデータのスケジューリングを示した代表的な流れ図である。 本発明に係る静的ＢＣＭＣＳデータフロー確立のメッセージを示した図である。

Claims (21)

1. ネットワークインタフェースを経由してアプリケーションサーバーと接続し、さらに複数の基地局を経由して複数の端末と接続する通信制御装置であって、
   前記アプリケーションサーバーから情報を受信し、前記基地局との間に確立されたマルチキャスト通信フローを利用して、前記情報を前記基地局に送信するネットワークインタフェースと、
   前記ネットワークインタフェースで新たなマルチキャスト通信フローを確立することを要求する要求情報を受信したとき、前記基地局との間にすでに確立されたその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、前記新たなマルチキャスト通信フローが経由する基地局に対して新たなマルチキャスト通信フローを確立できるかどうかを判断し、前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立する制御部とを有することを特徴とする、通信制御装置。
2. 前記通信品質パラメータが通信帯域であり、
   前記制御部は、前記ネットワークインタフェースで新たなマルチキャスト通信フローを確立することを要求する要求メッセージを受信したとき、前記新たなマルチキャスト通信フローが経由する基地局のすでに確立されたマルチキャスト通信フローの通信帯域の和と前記新たなマルチキャスト通信フローの通信帯域の和が前記基地局の通信帯域制限を超えるかを判断することにより、新たなマルチキャスト通信フローを確立できるかどうかを判断し、その結果が超えないとなるとき、新たなマルチキャスト通信フローを確立することを特徴とする、請求項１に記載の通信制御装置。
3. 前記ネットワークインタフェースで前記マルチキャスト通信フローを１つの通信トンネルに入れて、各基地局に情報を送信し、
   前記ネットワークインタフェースで前記新たなマルチキャスト通信フローを確立することを要求する情報を受信したとき、前記制御部は前記新たなマルチキャスト通信フローが経由する基地局に対して、前記トンネルにおけるその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、各基地局に対して、新たなマルチキャスト通信フローを確立できるかどうかを判断し、前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立することを特徴とする、請求項１に記載の通信制御装置。
4. さらに、前記マルチキャスト通信フローを識別するためのマルチキャスト通信フローＩＤと、前記各基地局との間に確立された前記通信トンネルを識別するための通信トンネルＩＤと、各前記マルチキャスト通信フローの通信品質パラメータとの対応関係を示すマルチキャスト通信フロー情報表が格納されているマルチキャスト通信フロー情報表を記憶するメモリを有し、
   前記制御部が前記マルチキャスト通信フロー情報表を参照して、前記判断を行い、
   前記ネットワークインタフェースが、前記新たなマルチキャスト通信フローを確立するかを示す情報を、前記アプリケーションサーバーに送信することを特徴とする、請求項３に記載の通信制御装置。
5. 前記通信品質パラメータは通信帯域および重み係数であり、
   前記制御部は、前記ネットワークインタフェースで新たなマルチキャスト通信フローを確立することを要求する情報を受信したとき、前記新たなマルチキャスト通信フローが経由する基地局との間にすでに確立された通信トンネルに含まれるその他のマルチキャスト通信フローの通信帯域と重み係数の積と、前記新たなマルチキャスト通信フローを経由する通信帯域と重み係数の積の和が、前記基地局の通信帯域制限を超えるかを判断し、各基地局の通信帯域制限を超えない場合、前記新たなマルチキャスト通信フローを確立し、
   前記新たなマルチキャスト通信フローの帯域と前記基地局の確立されたマルチキャスト通信フローの通信帯域の和が前記基地局の帯域制限を超えていることを特徴とする、請求項３に記載の通信制御装置。
6. 前記制御部は、前記通信トンネルに含まれる前記マルチキャスト通信フローが前記通信トンネルの通信リソースを共用するよう、ネットワークインタフェースを制御することを特徴とする、請求項５に記載の通信制御装置。
7. 前記通信品質パラメータは、端末の登録プロセスにおいて、前記端末から前記アプリケーションサーバーを経由して送信されるＩＮＶＩＴＥメッセージから取得されることを特徴とする、請求項５に記載の通信制御装置。
8. 前記重み係数は、前記マルチキャスト通信フローがどのタイプの通信であるかによって決められることを特徴とする、請求項５に記載の通信制御装置。
9. 前記マルチキャスト通信フロー情報表は、前記端末の通信停止時に更新されることを特徴とする、請求項４に記載の通信制御装置。
10. 前記基地局の帯域が前記マルチキャスト通信フローの同時通信の需要を満たすことができないとき、その中の一部のマルチキャスト通信フローに対してバッファリングを行うことを特徴とする、請求項５に記載の通信制御装置。
11. 前記基地局が無線基地局であることを特徴とする、請求項１〜１０のいずれかに記載の通信制御装置。
12. アプリケーションサーバーから情報を受信し、複数の基地局との間に確立されたマルチキャスト通信フローを利用して、前記情報を前記基地局に送信する通信制御方法であって、
    アプリケーションサーバーから新たなマルチキャスト通信フローを確立することを要求する要求情報を受信する受信ステップと、
    前記基地局との間にすでに確立されたその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、前記新たなマルチキャスト通信フローが経由する基地局に対して新たなマルチキャスト通信フローを確立できるかどうかを判断する判断ステップと、
    前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立するマルチキャスト通信フロー確立ステップと、を含むことを特徴とする通信制御方法
13. 前記通信品質パラメータが通信帯域であり、
    前記判断ステップで前記新たなマルチキャスト通信フローが経由する基地局のすでに確立されたマルチキャスト通信フローの通信帯域の和と前記新たなマルチキャスト通信フローの通信帯域の和が前記基地局の通信帯域制限を超えるかを判断することにより、新たなマルチキャスト通信フローを確立できるかどうかを判断し、前記マルチキャスト通信フロー確立ステップにおいてその結果が超えないとなるとき、新たなマルチキャスト通信フローを確立することを特徴とする、請求項１２に記載の通信制御方法。
14. 前記マルチキャスト通信フローを１つの通信トンネルに入れて、各基地局に情報を送信し、前記判断ステップで前記新たなマルチキャスト通信フローが経由する基地局に対して、前記トンネルにおけるその他のマルチキャスト通信フローの通信品質パラメータと前記新たなマルチキャスト通信フローの通信品質パラメータに基づき、各基地局に対して、新たなマルチキャスト通信フローを確立できるかどうかを判断し、前記マルチキャスト通信フロー確立ステップにおいて前記新たなマルチキャスト通信フローが経由する基地局に対する前記判断の結果がＹＥＳである場合、前記新たなマルチキャスト通信フローを確立することを特徴とする、請求項１２に記載の通信制御方法。
15. さらに、前記マルチキャスト通信フローを識別するためのマルチキャスト通信フローＩＤと、前記各基地局との間に確立された前記通信トンネルを識別するための通信トンネルＩＤと、各前記マルチキャスト通信フローの通信品質パラメータとの対応関係を示すマルチキャスト通信フロー情報表が格納されているマルチキャスト通信フロー情報表を記憶するメモリを有し、
    前記判断ステップで前記マルチキャスト通信フロー情報表を参照して、前記判断を行い、
    前記新たなマルチキャスト通信フローを確立するかを示す情報を、前記アプリケーションサーバーに送信することを特徴とする、請求項１４に記載の通信制御方法。
16. 前記通信品質パラメータが通信帯域および重み係数であり、
    前記判断ステップで前記新たなマルチキャスト通信フローが経由する基地局との間にすでに確立された通信トンネルに含まれるその他のマルチキャスト通信フローの通信帯域と重み係数の積と、前記新たなマルチキャスト通信フローを経由する通信帯域と重み係数の積の和が、前記基地局の通信帯域制限を超えるかを判断し、
    前記マルチキャスト通信フロー確立ステップにおいて各基地局の通信帯域制限を超えないと判断した場合、前記新たなマルチキャスト通信フローを確立し、
    前記新たなマルチキャスト通信フローの帯域と前記基地局の確立されたマルチキャスト通信フローの通信帯域の和が、前記基地局の帯域制限を超えていることを特徴とする、請求項１５に記載の通信制御方法。
17. 前記通信トンネルに含まれる前記マルチキャスト通信フローが前記通信トンネルの通信リソースを共用することを特徴とする、請求項１６に記載の通信制御方法。
18. 前記通信品質パラメータは端末の登録プロセスにおいて、前記端末から前記アプリケーションサーバーを経由して送信されるＩＮＶＩＴＥメッセージから取得されることを特徴とする、請求項１６に記載の通信制御方法。
19. 前記重み係数は、前記マルチキャスト通信フローがどのタイプの通信であるかによって決められることを特徴とする、請求項１６に記載の通信制御方法。
20. 前記マルチキャスト通信フロー情報表は、前記端末の通信停止時に更新されることを特徴とする、請求項１５に記載の通信制御方法。
21. 前記基地局の帯域が前記マルチキャスト通信フローの同時通信の需要を満たすことができないとき、その中の一部のマルチキャスト通信フローに対してバッファリングを行うことを特徴とする、請求項１６に記載の通信制御方法。
    

Images