JP2004531179A - ポイントツーポイントパケット交換向きのネットワークにおけるマルチキャスト方法 - Google Patents
ポイントツーポイントパケット交換向きのネットワークにおけるマルチキャスト方法 Download PDFInfo
- Publication number
- JP2004531179A JP2004531179A JP2003509703A JP2003509703A JP2004531179A JP 2004531179 A JP2004531179 A JP 2004531179A JP 2003509703 A JP2003509703 A JP 2003509703A JP 2003509703 A JP2003509703 A JP 2003509703A JP 2004531179 A JP2004531179 A JP 2004531179A
- Authority
- JP
- Japan
- Prior art keywords
- multicast
- multicast group
- router
- sgsn
- transport
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/246—Connectivity information discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/32—Connectivity information management, e.g. connectivity discovery or connectivity update for defining a routing cluster membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/34—Modification of an existing route
- H04W40/36—Modification of an existing route due to handover
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Design And Manufacture Of Integrated Circuits (AREA)
- Cartons (AREA)
- Packages (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本発明は、ポイントツーポイントでのパケット交換向きの通信ネットワークでマルチキャストを実行する方法、ネットワークノード、ルータ、在圏ノード、及びシステムに関する。基本的概念は、ネットワークの各部分に事前に設定されたマルチキャスト伝送を導入することである。これは、マルチキャストデータを転送するために、ルータと在圏ノードとの間に事前に設定されたトランスポートマルチキャストグループトンネルを作成することによって実現される。さらに、本発明では、事前に設定されたトランスポートマルチキャストグループトンネル上でマルチキャストデータストリームを多重化する可能性について説明する。特に、本発明は、リソースの少ないＵＭＴＳなどの各ネットワーク、すなわち、例えば、Ｇｎインタフェース上でのＳＧＳＮとＧＧＳＮとの間のＩＰネットワークにおけるマルチキャスティングに適用可能である。
Description
【技術分野】
【０００１】
本発明は、通信網においてマルチキャストを実行する方法、ネットワークノード、ルータ、在圏ノード、及びシステムに関する。
【０００２】
本願は、特に、ポイントツーポイントパケット交換通信ネットワークにおいて適用可能である。
【背景技術】
【０００３】
マルチキャスティングとは、同一のデータのコピー１部をあるアドレスに送信することで、発信元が複数の受信者にデータを配信できるようにするサービスである。マルチキャスティングでは、メッセージのコピー１部だけがネットワーク内のリンクを通過し、経路が分岐する地点で複数部のコピーが作成される。ネットワークの観点から見て、マルチキャストは全体的な帯域幅の使用量を大幅に削減する。これは、データがエンドシステムにおいてではなく、ネットワークの適切なポイントで複製されるためである。また、マルチキャストメッセージを送信するサーバは１つのセッションを管理するだけで良い。
【０００４】
これまで長年にわたりローカルエリアネットワークがマルチキャスティングをサポートしてきた。各ノードが共通の通信媒体を共有するようなネットワークでは、マルチキャスティングをサポートするのは容易である。特別なアドレスを指定されたパケットは、この通信媒体から複数のホストにより読み出すことができる。
【０００５】
マルチキャスティング機能をインターネットワークへと拡張するには、到着するデータパケットをどのように転送するかを動的に解決するためにネットワークの終端にルータを導入することが必要であろう。転送方法は、例えば、データパケットのヘッダに含まれるアドレス及びルータで管理されるルーティングテーブルから決定される。例えば、マルチキャストグループを示すアドレスを使用するためにマルチキャストアドレス指定を実行する可能性はほとんどない。
【０００６】
インターネットプロトコル（ＩＰ）ネットワークで使用されるマルチキャストは、ＩＰマルチキャストと呼ばれる。ＩＰマルチキャスト内では、マルチキャストセッショングループのメンバシップは動的である。これは、ホストが随時グループに参加してもグループから脱退しても良いことを意味する。ネットワーク上のホストが、特定のマルチキャストグループへの参加又はグループからの脱退を希望するか否かを表明できるようにするために、インターネットグループメッセージプロトコル（ＩＧＭＰ）と呼ばれるプロトコルが存在する。このプロトコルにより、システムは、現在どのホストがどのマルチキャストグループに所属しているのかを知ることができる。この情報は、マルチキャストルータが、どのマルチキャストデータパケットがどのインタフェースへと転送されるべきかを知るのに必要である。
【０００７】
ＩＧＭＰはＩＰレイヤの一部であり、ＩＧＭＰメッセージはＩＰデータパケットの形態で伝送される。ＩＧＭＰのバージョン１は、ＲＦＣ１１１２「Host extensions for IP multicasting」（S.E. Deering、１９８９年８月１日）に記載されている。ＲＦＣ２２３６「Internet Group Management Protocol, Version 2」（W. Fenner、１９９７年１１月）には、バージョン２が記載されている。ＩＧＭＰは、ＩＰバージョン４に対して開発されたものである。インターネットプロトコル（ＩＰ）バージョン６では、マルチキャスト受信者探索（ＭＬＤ）と呼ばれる同様のプロトコルがあり、ＩＧＭＰと同じ目的で使用される。ＭＬＤの第1バージョンについての説明は、ＲＦＣ２７１０「Multicast Listener Discovery (MLD) for IPv6」（S. Deering, W. Fenner, B. Haberman、１９９９年１０月）に記載されている。ＭＬＤで使用されるメッセージはＩＧＭＰメッセージに対応している。以下の説明ではＩＧＭＰが一例として使用されているが、ＩＧＭＰに限定されるべきではない。本発明の機能はＭＬＤの使用によっても得られる。
【０００８】
原則として、ＩＧＭＰはそのタスクを遂行するために２つの基本的なメッセージを使用する。メンバシップ報告メッセージ及びメンバシップクエリー（問い合せ）メッセージであり、以下の規則が適用される。異なるバージョンのＩＧＭＰも追加のメッセージを含む。
【０００９】
マルチキャストルータは、ホストがグループに所属しているか否かを確認するために一定間隔でメンバシップクエリーを送信する。ルータは、インタフェースごとに１つのクエリーを送出しなければならない。各ホストの１以上のメンバを含むグループごとに１つの応答をホストから受信することをルータは期待するので、クエリーのグループアドレスは０である。全てのグループに対してではなく、ある特定のグループにメンバシップクエリーを送信することもできる。ホストは、少なくとも１つのユーザを含むグループごとに１つのＩＧＭＰ報告を送信することでＩＧＭＰクエリーに応答する。また、ホストはメンバシップ報告を送信することによってグループに参加する。
【００１０】
報告メッセージ及びクエリーメッセージを適用することで受信される情報を使用して、マルチキャストグループ内の少なくとも１台のホストを有するインタフェースを伴うテーブルが構築される。ルータは、受信されたマルチキャストデータを、インタフェースを介して転送する。このインタフェースは少なくとも１つのメンバを有する。
【００１１】
ＩＰマルチキャストにより、受信者は送信者が誰であるか及びどこでトラフィックを受信するかを知る必要がなく、送信者は受信者が誰であるかを知る必要がなくなる。ネットワークが配信を最適化するため、送信者も受信者もネットワークトポロジについて考慮する必要はない。ＩＰマルチキャストを介する情報の配信は、例えば、マルチキャスト配信ツリーのようなホストの階層的な接続に基づいて実行される。スパンニングツリー、共有ツリー、送信元ツリー、コアベースツリーのようなマルチキャスト配信ツリーを構築するために、幾つかのアルゴリズムが提示されている。対応するアルゴリズムの説明は、「IP telephony: Packet based multimedia communications systems」（O. Hersent, D. Gurle, D. Petit, Addison Wesley, Harlow、2000）にある。マルチキャスト配信ツリーの構築後、ＩＰマルチキャストルーティングプロトコルにより情報の配信が行なわれる。対応するＩＰマルチキャストルーティングプロトコルの詳細な説明も上述の文献において見出される。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
ＩＰマルチキャストの利点は、異質の受信者をサポートしていることである。ＩＰマルチキャストにより、異なる媒体（メディア）を異なるマルチキャストグループに送信することが可能になり、受信者は自己の能力及び／又は好みに応じてどの媒体を受信するかを決定することが可能となる。同様に、送信者がビデオストリーム又は音声ストリームを階層（レイヤ）化する場合、各受信者は異なるトラフィック量及び異なる品質を選択することができる。これを実現するには、送信者が許容最低品質であるベースレイヤと複数の拡張レイヤとしてビデオを符号化しなければならない。拡張レイヤが１層加わるごとに品質は向上するが追加の帯域幅が必要となる。ビデオに関して、これらの追加のレイヤによって、フレームレートの増加、画像の空間分解能の向上、あるいは、その双方が実現されるであろう。各レイヤは異なるマルチキャストグループへと送信されるため、受信者は受信を申し込むレイヤの数を個別に決定することができる。
【００１３】
固定網と汎用パケット無線システム（ＧＰＲＳ）又はユニバーサル移動通信システム（ＵＭＴＳ）などの移動網との間のインターネットワーキングにおけるマルチキャスティングでは、さらなる問題が発生する。この問題は、例えば、エンドユーザの移動性及びエアインタフェースにおける移動網の伝送帯域幅の狭さに起因している。また、ＵＭＴＳなどの移動通信網における通信はユニキャスト通信である。ユニキャスト通信はポイントツーポイント通信とも呼ばれる。ポイントツーポイント通信とは、１人の送信者から１人の受信者へとメッセージを送信することを意味する。このようなネットワーク、特に、コアネットワークでは、マルチキャスト通信を実行することは想定されていない。グループ通信は、送信者がグループの各メンバに個別にポイントツーポイント通信によってパケットを送信することで実現される。ｎ人のメンバを有するグループの場合、マルチキャスト伝送が使用されるときには１個のパケットで良いのに対し、送信者と受信者との間で全体としてｎ個のパケットが必要である。
【００１４】
以下の記述では、ポイントツーポイント向きの通信システムにおいて発生する問題を説明するために、汎用パケット無線システム（ＧＰＲＳ）ネットワークのアーキテクチャの概要を示すことにする。
【００１５】
ＧＰＲＳは、回線交換網である移動通信用グローバルシステム（ＧＳＭ）をパケット交換へと拡張したものである。これによれば、ユーザは常時オンライン接続しつつも、実際のデータ転送に対してのみ料金を支払えば良いことを意味する。新規の必要条件を満たすために、幾つかの変更がＧＳＭ、とりわけ、新規の論理ノードに導入される。すなわち、サービング（在圏）ＧＰＲＳサポートノード（ＳＧＳＮ）及びゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）が導入される。ＧＧＳＮの主な機能は、例えば、インターネットサービスプロバイダ（ＩＳＰ）への接続を提供する外部のＩＰパケット網との相互作用を含む。外部のＩＰネットワークの観点から見ると、ＧＧＳＮは、ＧＰＲＳネットワークによるサービスを受ける全ての加入者のＩＰアドレスに対するルータとして機能する。また、ＧＧＳＮは、ルーティング情報を外部のネットワークと交換する。ＳＧＳＮは、地理的なＳＧＳＮサービスエリア内に物理的に位置している全てのＧＰＲＳ加入者に対してサービスを提供する。ＳＧＳＮは、移動局宛の受信ＩＰパケット又は移動局からの送信ＩＰパケットを転送する。新規の論理ノードに加えて、ノード間の新規のインタフェースが定義される。本発明では、特に、Ｇｎインタフェース、Ｇｉインタフェース、Ｇｐインタフェースが関係する。Ｇｐインタフェースは、異なるオペレータに所属するＧＧＳＮノード間で定義される。Ｇｎインタフェースは、ＳＳＧＮとＧＧＳとの間のＩＰベースのバックボーンを定義する。Ｇｉは、ＧＧＳＮとインターネットなどのさらに別のネットワークとの間のインタフェースである。ＧＰＲＳへの制限は、選択された技術の上でＩＰが実行されることでＧＧＳＮとＳＳＧＮとが接続されなければならないことである。これは、ＳＧＳＮ及びＧＧＳＮがＩＰアドレスを介して通信することを意味する。アーキテクチャの詳細な説明は、3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)にある。
【００１６】
同様のノード及びインタフェースは、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に記載されているように、次世代の無線ネットワーク、すなわち、ＵＭＴＳでも使用される。ＵＭＴＳにおけるこれらのノードの機能を区別するために、拡張名（３Ｇ−ＳＧＳＮ及び３Ｇ−ＧＧＳＮ）を使用することにする。以下の説明では、ＧＰＲＳノードとＵＭＴＳノードとの間で区別はしない。
【００１７】
以下の説明では、上述のようなthe 3GPP specifications, UMTS Standard 23.060で規定されるようなＵＭＴＳネットワークの概要を示す。
【００１８】
図１は、Ｐａｃｋｅｔとして示されるパケット交換ドメインとしてのコアネットワークを示している。コアネットワークは、Ｒａｄｉｏ ＮＷとして示される無線ネットワークに接続される。コアネットワークのパケット交換ドメインの上には、ＩＰマルチメディアサブシステム（ＩＭＳ）、すなわち、会話型マルチメディアサービスのためのＩＰ Ｍｕｌｔｉｍｅｄｉａ（ＩＰマルチメディア）がある。各サブシステムは対応するノードを含む。本発明において関連するのは、コアネットワークのノード、すなわち、関係するインタフェースＧｎ、Ｇｉを有するＳＧＳＮノード及びＧＧＳＮノードである。これらのインタフェースについては後で詳細に説明する。同様に関連するＧｐインタフェースは図１に示されていない。一例としてのＩＭＳは、パケット交換ドメインを使用して、会話型マルチメディアサービスへのベアラを提供する。例えば、対応するパケット交換ベアラの上部のインターネットにおいてストリーミングサーバを使用することによって、ＩＭＳなしでもストリーミングマルチメディアサービスを実現可能である。
【００１９】
ストリーミング／会話型マルチメディアサービスの導入により、多くの新規のポイントツーマルチポイントサービスが進化するであろう。これらのサービスは、ネットワークインフラストラクチャに対する要求が高く、かなりの帯域幅を使用する。これらのサービスの例としては、ビデオ会議、電子黒板、リアルタイムマルチユーザゲーム、マルチメディアメッセージング、仮想世界などがある。
【００２０】
図１によると、インターネットのような外部のＩＰネットワークがＭｕｌｔｉｍｅｄｉａ／ＩＰ Ｎｅｔｗｏｒｋ（マルチメディア／ＩＰネットワーク）として示され、移動局はＴＥ、コアネットワークはＰａｃｋｅｔとして示されている。現在、ＵＭＴＳにおけるＩＰマルチキャストメッセージは、外部のＩＰネットワークに設置されるルータから移動局までユニキャスト接続を介して透過的に送信される。既に説明したように、マルチキャストはＩＰレイヤ上で実行される。移動局ＴＥの観点から見ると、インターネットのルータはＩＰ接続が終了する最初のノードであり、マルチキャストに適用可能な最初のノードである。これは、外部ネットワークに対する通信を可能にするＧＧＳＮのＩＰレイヤがマルチキャストを実行可能とは、現在のところ想定されていないことを意味する。ルータは、マルチキャストメッセージとユニキャストメッセージとを区別せずに、移動網のコア部分内でマルチキャストメッセージを送信する。マルチキャストフローの分離はインターネットのルータで既に行なわれており、同じデータパケットが受信者の人数に応じて複数回無線ネットワークを介して送信される。
【００２１】
これは、既存のＵＭＴＳ技術が、図１のＧｎインタフェースとして示されるネットワークの部分での効率的なマルチキャスティングの利用を想定していないことを意味する。複数のクライアントに同時に提供されるサービスは、無線ネットワークの終端で複製され、複数のユニキャスト接続がクライアントに対して使用される。特に、リソースの需要が高いストリーミングマルチメディアサービス又は会話型マルチメディアサービスの進化においては、ネットワークのリソースが非効率的に使用されることを意味する。
【００２２】
さらに、既存のノードは、マルチキャスティングを実行するように構成されていない。
【００２３】
一般に、ポイントツーポイント向きののネットワークでマルチキャストを導入・実行すると本質的な問題が発生する。このようなネットワークでは、２台のノード間の通信を実行するためにユニキャストチャネルが確立される。これは、ＵＭＴＳのような無線ネットワークでのみ問題が発生するのではないことを意味する。
【００２４】
マルチキャストが可能なプロトコルのさらなる例としては、ＳＩＰ（セッション開始プロトコル）又はＲＴＳＰ（リアルタイムストリーミングプロトコル）がある。ＳＩＰプロトコルは、ＩＥＴＦのマルチパーティ・マルチメディア・セッション・コントロール（ＭＭＵＳＩＣ）ＷＧに記載されており、ＲＴＳＰは、RFC 2326 「Real Time Streaming Protocol (RTSP)」（H. Schulzrinne, A. Rao, R. Lanphier、１９９８年４月）によりカバーされている。これらのプロトコルは、ポイントツーポイント向きのプロトコルに所属し、以下に説明する発明もこれらのプロトコルに適用される。
【００２５】
本発明の目的は、ポイントツーポイント向きのパケット交換通信ネットワークにおけるマルチキャストの効率的な導入・実行に対する解決法を提供することである。
【課題を解決するための手段】
【００２６】
本発明は、請求項１、２４、２６、及び２７に開示される方法、ルータ、在圏ノード、及びシステムにおいて具象化される。有利な実施例は各従属請求項に記載される。
【００２７】
基本的概念は、ＧＧＳＮなどの少なくとも１台のルータと、少なくとも１つのユーザ装置を処理する少なくとも１台の在圏ノードとを有するポイントツーポイント向きのパケット交換通信ネットワークの各部に接続するマルチキャストグループに対して、事前に設定・確立されたデフォルトのマルチキャスト伝送を使用することである。ユーザ装置は例えば移動局などであり、在圏ノードは例えばＳＧＳＮなどであり、ポイントツーポイント向きのパケット交換通信ネットワークは例えばＵＭＴＳなどである。前記ネットワークは、それ自体で複数のマルチキャストグループを提供することができる。当該ネットワークは、登録可能な複数のマルチキャストグループを有するさらなるネットワークに接続することができる。さらなるネットワークとは例えばインターネットなどである。事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、前記ルータと前記在圏ノードとの間にＧＴＰなどのトンネリング用のトランスポートレイヤプロトコルにより事前に確立され、当該トンネルがマルチキャストグループに対して割り当てられる。複数のマルチキャストデータストリームが前記トンネルについての事前設定に合致する場合、前記ルータは、前記ストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化する可能性がある。マルチキャストデータの伝送は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して、前記ルータから前記在圏ノードに対して実行される。対応するマルチキャストグループに登録されたユーザに対してデータを転送するために、必要に応じてマルチキャストデータの非多重化（分離処理）が前記在圏ノードにおいて行なわれる。
【００２８】
前記在圏ノードは、前記マルチキャストグループに登録され、かつ前記在圏ノードによりシャンデルされるユーザが２以上いる場合、前記複数のマルチキャストデータストリームの複製を行なう。
【００２９】
さらなる記述において、ユーザの説明を行なうのに一例として移動局が使用されるが、ノードをユーザと見なすこともできる。一般的に、ユーザはマルチキャストグループのメンバを意味する。
【００３０】
本発明の好適な実施例では、前記トランスポートレベルのマルチキャストグループトンネルの事前設定は、複数の異なるサービスクラスに従って行なわれる。例えば、ＵＭＴＳでは、サービス品質ＱｏＳにおいて異なる必要条件を有するストリーミングサービスクラス又は会話型サービスクラスのような複数の異なるサービスクラスが存在する。これらの必要条件によると、所要のＱｏＳ必要条件をサポートする事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。この方法の有利な実施例では、負荷分散及び冗長性のために２以上の事前に設定されたトランスポートレベルのマルチキャストグループトンネルが確立される。これは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと前記サービスクラスの組み合わせを構築できることを意味する。例えば、ストリーミングサービスクラスに対して、２つの事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。
【００３１】
別の実施例では、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、別のパラメータ、すなわち、都市又は国などの地理的領域に従って確立することができる。ＳＧＳＮなどの１台以上の在圏ノード又はＧＧＳＮなどの１台以上のルータによりカバーされるエリアも地理的領域を定義することができる。さらなるパラメータの組み合わせも定義することができる。例えば、特定の地理的領域に対して、異なるサービスクラスを有する複数の事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。
【００３２】
前記在圏ノードは、前記ルータに対してトランスポートレベルのマルチキャストグループへの接続又は前記グループからの解放に対する関心を通知するのが好ましい。前記トランスポートレベルのマルチキャストグループは、ユーザが登録することのできるマルチキャストグループに関連している。トランスポートレベルのマルチキャストグループの各メンバへのマルチキャスト伝送は、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して行なわれる。
【００３３】
また、前記ルータが在圏ノードに対して前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルの確立を管理することも可能である。これは管理インタフェースにより行なわれ、たとえば、在圏ノードがネットワークに接続される開始手順中に行なうことができる。前記ルータは、前記在圏ノードの各パラメータを受信し、これらのパラメータに従ってトランスポートレベルのマルチキャストグループトンネルが確立される。
【００３４】
前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、事前に設定されたマルチキャスト配信ツリーを使用する。この配信ツリーは、前記ルータと少なくとも１台の在圏ノードとの間に作成される。前記ツリーはマルチキャストルーティングプロトコルにより確立される。
【００３５】
マルチキャストグループは、対応するサービスクラスのマルチキャストトンネルの上でトラフィックを送信するのに、サービスクラスにより提供されるＱｏＳ特性を必要とする。この関係で、マルチキャストグループはサービスクラスに所属していると言うことができる。本発明の好適な実施例では、同じサービスクラスに所属する複数のマルチキャストグループの多重化が、前記サービスクラスをサポートするために事前に設定された同一のトランスポートレベルのマルチキャストグループトンネル上で行なわれる。
【００３６】
前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを管理するために、データ構造を使用することが想定される。データ構造のタスクは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記マルチキャストグループの登録ユーザと、前記マルチキャストグループのマルチキャストアドレスとの関連付けを管理することである。前記データ構造は、ネットワークノードにおいて集中管理することも、あるいは、ネットワーク内で分散管理することもできる。
【００３７】
特に、これは、前記ルータ及び／又は前記在圏ノードにおいて、あるいは、１つ又は複数の他のネットワークエンティティによりデータ構造を管理することができることを意味する。
【００３８】
本発明の好適な実施例において、特定のサービスクラスを要求するユーザが、事前に設定されたどのトランスポートレベルのマルチキャストグループトンネルに割り当てられるべきかを決定するために、前記データ構造は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと前記サービスクラスとの間の関係を含む。
【００３９】
本発明の好適な実施例では、前記在圏ノードはユーザに対して中継するマルチキャストデータパケットの個数と破棄するマルチキャストデータパケットの個数とについての統計値を収集し、その結果によりトランスポートレベルのマルチキャストグループへの登録を解除する決定が下される。マルチキャストから得られるよりも、マルチキャストトラフィックを破棄するのにより高い処理能力が必要とされるので、前記在圏ノードはこの情報に基づいてＴＬＭＧへの登録の解除を決定しても良い。
【００４０】
本発明の好適な実施例では、前記在圏ノードは事前に設定されたトランスポートレベルのマルチキャストグループトンネルの一部になることを望むか否かを決定する。どの在圏ノードに前記マルチキャストデータが送信されるかを見出すためには、事前に設定されたトランスポートレベルのマルチキャストグループトンネルに登録された在圏ノードの台数を管理するのが好ましい。しかし、前記ルータは、何台の及びどの在圏ノードが対応するトランスポートレベルのマルチキャストグループに接続されるかの情報を入手することなく、前記トランスポートレベルのマルチキャストグループトンネルにデータを送信することもできる。
【００４１】
好適な実施例では、前記複数のマルチキャストデータストリームは、事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化される。前記受信中の多重化された複数のデータストリームを分離するためには、前記在圏ノードはマルチキャストグループの一部であるユーザを判定すべく、各ストリームを区別するパラメータを管理する。これは、例えば、さらなるネットワークに存在するマルチキャストグループのマルチキャストアドレスであっても良く、アドレスはデータパケットに含まれる在圏ノードへと送信される。
【００４２】
本発明による方法を実行するために、登録及び登録解除手順が定義されるべきである。好適な実施例では、ユーザのマルチキャストグループへの登録又はマルチキャストグループへの登録解除を行なうために、ユーザは前記ルータに対して通知し、前記ルータは前記在圏ノードに通知し、前記データ構造中の対応するエントリの更新が行なわれる。
【００４３】
移動網は、特に、ユーザの移動により特徴づけられる。従って、手順が適用されると、データの連続的な受信が保証されることになる。このため、ユーザが前記在圏ノードを変更する場合、ユーザの新規の在圏ノードへの登録、以前の在圏ノードからの削除、及び前記ルータ中の前記対応するエントリの更新が実行される。
【００４４】
この手順としては、メッセージ交換を信号で通知するための制御シグナリングプロトコルが使用される。また、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立するために使用される前記トンネリング用のトランスポートレイヤプロトコルは前記プロトコルの一例である。
【００４５】
前記制御シグナリングプロトコルの一例は、ＵＭＴＳで使用されるようなＧＰＲＳトンネリングプロトコル（ＧＴＰ）である。
【００４６】
本発明の有利な実施例では、マルチキャストグループのマルチキャストアドレスの代わりに、ＧＴＰで定義されるＧＴＰトンネリングＩＤ（ＴＩＤ）を前記在圏ノード中の前記複数のマルチキャストストリームを分離するための識別用パラメータとして使用することができる。
【００４７】
本発明の好適な実施例では、前記マルチキャストは、マルチキャスト対応ルータに含まれるマルチキャスト・ルーティング・テーブルに従ってユーザへのルートを定義するために、ＩＰマルチキャストアドレスを有するＩＰパケットを使用するＩＰマルチキャストである。
【００４８】
マルチキャストグループへの登録及びマルチキャストグループからの解放のために、既存のＩＧＭＰ又はＭＬＤプロトコルを使用することも好ましい。これらは周知のプロトコルであり、本発明の好適な実施例では、ネットワークリソースを節約するために変更される。これは、現在、前記ルータがＩＧＭＰ要求メッセージによりマルチキャストグループへの登録が行なえる態勢にあるかユーザに尋ねることを意味する。このＩＧＭＰメンバシップクエリーは定期的に送信される。伝送リソースを節約するためには、ユーザが希望に応じてマルチキャストグループに登録する方がより効率的である。
【００４９】
通信ネットワーク内でマルチキャスト伝送を行なうようにルータを適合させることが提案されている。前記ルータは、前記在圏ードに対して事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立するためのロジック（論理手段）を有する。さらに、前記ルータは、前記複数のマルチキャストデータストリームが前記トンネルの事前設定と一致する場合に、複数のマルチキャストデータストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化するためのロジックを含む。また、前記ルータは、マルチキャストデータを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して前記在圏ノードへと転送するためのロジックを含む。これは、例えば、さらなるネットワークから前記マルチキャストデータを受信することと、受信者のアドレスを分析することと、前記アドレスの前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへの変換と、前記マルチキャストデータをこのトンネルに送信することとを含む。
【００５０】
前記ルータが前記さらなるネットワークへと前記マルチキャスト登録を伝播するためのロジックを含むことも提案されている。ユーザがマルチキャストグループに登録している第１のユーザである場合に伝播処理が必要である。これは、前記さらなるネットワーク中の隣接するルータに対し、対応するグループのマルチキャストデータを送信されるべき特定のマルチキャストグループに、少なくとも１つのメンバがいることを通知する必要があることを意味する。
【００５１】
前記ルータが、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記マルチキャストグループの登録ユーザと、前記マルチキャストアドレスとの関連付けの管理用のデータ構造を制御することが提案される。
【００５２】
さらに、在圏ノードは、通信ネットワーク内でマルチキャストを行なうように構成される。在圏ノードは、前記事前に設定されたトランスポートマルチキャストグループトンネル上で前記ルータからマルチキャストデータを受信するためのロジックを有する。前記事前に設定されたトランスポートレベルのマルチキャストグループと対応するマルチキャストグループに登録されたユーザとを管理するためのロジックは、事前に設定されたトランスポートレベルのマルチキャストグループトンネルからどのユーザにデータが送信されるかを知るために必要とされる。さらに、在圏ノードは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で複数のマルチキャストデータストリームが多重化されている場合にこれらを分離するためのロジックを必要とする。２以上のユーザがいる場合、マルチキャストデータは前記ユーザ間で前記受信されたマルチキャストデータを複製するためのロジックにより複製される。
【００５３】
さらに、ルータと複数のユーザを処理する在圏ノードとを有する通信ネットワーク内でマルチキャストを行なうように構成されるシステムを有することが提案される。上述の特徴により、各ノードの機能が拡張され、システムは上述の方法に従って動作する。
【００５４】
ＵＭＴＳなどのモバイル環境において、在圏ノードの一例であるＳＧＳＮとルータの一例であるＧＧＳＮとの間のＩＰネットワークの伝送を効率的にするために、ＩＰマルチキャストを使用することによって、これらの技術思想は実現できるであろう。
【００５５】
本発明の利点は、無線ネットワークにおいて乏しくかつ高価なネットワークリソースを効率的に利用できることである。
【００５６】
さらに、Ｇｎインタフェース及びＧｐインタフェースの場合、各リンク上でパケットのコピーを１つだけ伝送することによって、ＧＰＲＳ又はＵＭＴＳの伝送を効率良くすることができる。これにより、同じマルチキャストグループに対して複数のユーザが、同じ又は異なるＳＧＳＮに位置する場合は、全体での伝送リソースを減少させることができ、輻輳防止のアルゴリズムの必要性や負荷分散アルゴリズムの必要性が限定的なものとなろう。
【００５７】
例えば、事前に設定されたトランスポートレベルのマルチキャストグループトンネルなど、ネットワークの各部について事前に設定されたマルチキャスト伝送を使用することにより、マルチキャストグループの設定時間を減少させることができる。これは、ユーザが特定のマルチキャストグループに登録又はグループから脱退する場合、あるいは、ユーザが在圏ＳＧＳＮを変更する場合に、マルチキャスト配信ツリーを確立する必要がないからである。さらに、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを使用することによって、拡張サービスの提供と、異なるマルチキャストグループの多重化とを、同一のトランスポートレベルのマルチキャストグループトンネル上で達成できる。
【００５８】
以下の記述では、事前に設定されたトランスポートレベルのマルチキャストグループトンネルに割り当てられるトランスポートレベルのマルチキャストグループをＴＬＭＧと呼ぶ。
【発明を実施するための最良の形態】
【００５９】
次に、本発明を詳細に説明する。図２及び図３を参照して説明を行なう。
【００６０】
ツリー構造を伴う図２の上部は、外部のＩＰネットワーク内でのマルチキャストを示している。ＩＰネットワークは、Ｇｉインタフェースを介してＧＧＳＮに接続される。ＧＧＳＮからＳＧＳＮへの伝送は、Ｇｎインタフェースを介して行なわれる。Ｇｎインタフェースでの伝送は複数のノードを介することができる。これは、図２の中央部に相互に接続されたノードにより示されている。下部は、異なる無線ネットワークを示しており、これらのネットワークは、それぞれ対応するＳＧＳＮからサービスが提供される。図２で最も重要な部分は、ネットワークの中央部、すなわち、Ｇｎインタフェースである。このＧｎインタフェースには、ＧＧＳＮから２台のＳＧＳＮへとトラフィックを転送するためにマルチキャスティングが適用される。ＳＧＳＮは、対応する無線アクセスネットワークへとトラフィックを転送する。
【００６１】
図３にはプロトコルの関連図が示されている。図３は、３ＧＰＰで標準化されているネットワークのアーキテクチャを示している。なお、このアーキテクチャは本発明を限定するものではない。図３は、Ｕｕインタフェースを介してアクセスネットワークＵＴＲＡＮと通信を行なう移動局ＭＳを示している。Ｉｕ−Ｐｓインタフェースは、ＵＴＲＡＮと３Ｇ−ＳＧＳＮとを接続するものである。３Ｇ−ＳＧＳＮは、Ｇｎインタフェースを介して３Ｇ−ＧＧＳＮと通信を行なう。図３は、ＵＭＴＳで使用される様々なノードの様々なプロトコルスタックの概要を提供する。以下の説明では、例えば、ＩＰ、ＰＰＰ、及びＵＤＰ／ＩＰとして示される、パケット交換ドメインにおける２種類のＩＰレイヤと、ＧＴＰ−Ｕレイヤとに絞って説明を行なう。図３では、他のプロトコルについて補足を目的として言及する。
【００６２】
ＳＧＳＮ又はＧＧＳＮのように上述したパケット交換向きのノードの機能及び通信方法については、上述の必要条件及び制限があるため、開発されたプロトコルスタックに影響を及ぼしている。ルータとして及び外部のネットワークへのインタフェースとして機能するために、ＧＧＳＮには、アプリケーションレイヤの下側にＩＰレイヤが導入されている。ＧＧＳＮとＳＧＳＮとの間ではＩＰネットワークを備えるには制限があるため、トランスポート手段としてＧＴＰ−Ｕレイヤの下位にＩＰ論理コネクションが導入されている。
【００６３】
従って、図３には２種類のＩＰレイヤが存在し、以下の説明では、アプリケーションＩＰレイヤとトランスポートＩＰレイヤとして示している。プロトコルスタックのアプリケーションＩＰレイヤは、アプリケーションプロトコルＡｐｐｌｉｃａｔ．の真下に位置し、移動局と３Ｇ−ＧＧＳＮとを接続している。このＩＰレイヤは、パケット交換網にとって透過的である。この透過性は、図３のＭＳから３Ｇ−ＧＧＳＮに至る直線により示される。第２のＩＰレイヤは、ＳＧＳＮとＧＧＳＮとＵＴＲＡＮとの間の伝送に使用されるトランスポートＩＰレイヤである。ペイロードトラフィックは、アプリケーション固有のトンネリングプロトコル、すなわち、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）によってカプセル化され、Ｇｎ及びＩｕ−ＰＳを介して転送される。ＧＴＰは、トンネリング用のトランスポートレイヤプロトコルの一例である。ＧＰＲＳにおいて、ＧＴＰプロトコルは、ＳＧＳＮとＧＧＳＮとの間でのみ使用される。ＧＴＰパケットは、トランスポートプロトコルとしてＵＤＰを使用する。なお、トンネルを形成するトンネリングプロトコルには様々なものがある。ＧＴＰはその一例に過ぎない。
【００６４】
ポイントツーポイント向きのパケット交換ネットワークへのマルチキャストの導入が図４に示される。図４は、プロトコルスタックの最上位にアプリケーションレイヤＡｐｐｌ．を有し、ネットワークレイヤ上にインターネットプロトコル（ＩＰ）又はポイントツーポイントプロトコル（ＰＰＰ）を有する移動局ＭＳを示している。下位の層はＬ１レイヤ及びＬ２レイヤとして示されているが、これは、それぞれのノードにおいて基礎となる物理的なネットワークに依存して異なる可能性があるからである。移動局からの論理ＩＰコネクション又はＰＰＰコネクションは、３Ｇ−ＧＧＳＮにおいて終端する。ＵＴＲＡＮ、３Ｇ−ＳＧＳＮ、及び３Ｇ−ＧＧＳＮの各ノード間では、トンネルを形成するのにＧＴＰ−Ｕプロトコルが使用される。ＧＴＰ−Ｕの下位には、ペイロード情報の転送用のプロトコルとしてＵＤＰを有するＩＰレイヤが位置する。
【００６５】
ここで示される技術思想は、例えば、ＧＴＰのようなトンネリングプロトコルより下側の層であるＩＰレイヤ上にマルチキャスト機能を導入することである。図４において、３Ｇ−ＳＧＳＮと３Ｇ−ＧＧＳＮとの間のマルチキャストとして示される陰影部によりこの思想を示している。Ｇｉインタフェース上のマルチキャスト陰影部からＧｎインタフェース上のマルチキャスト陰影部へと向かう矢印は、アプリケーションＩＰレイヤ上で実行されるマルチキャストをトランスポートＩＰレイヤへと導入することを示している。これは、Ｇｉインタフェースを介して３Ｇ−ＧＧＳＮに到着するマルチキャストデータの宛先が、ＧＧＳＮとＳＧＳＮとの間のマルチキャストを実行する下層のＩＰレイヤに変更されることを意味する。ＵＴＲＡＮにおけるＳＧＳＮとＲＮＣとの間のコネクションはユニキャストのままである。また、ＩＰレイヤ上の論理ポイントツーポイントのコネクションも残されている。
【００６６】
以下の説明では、本発明で必要とされるＧＧＳＮの拡張機能が説明される。
【００６７】
新規のタスクを実行するために、ＧＧＳＮは、加入者から送信されるＩＧＭＰメッセージ又はＭＬＤメッセージを処理可能なローカルマルチキャストルータとして機能しなければならない。ＧＧＳＮは、ＩＧＭＰメッセージ又はＭＬＤメッセージを終端させ、関連する情報をＩＧＭＰ又はＭＬＤを介して隣接するルータへと転送する。ＧＧＳＮはマルチキャストルーティングプロトコルも扱う。加入者はＧＧＳＮの特定のマルチキャストグループに登録し、ＧＧＳＮはパケット交換網のアクティブなマルチキャストグループを常時監視する。これまでの説明では、ＧＧＳＮは標準のローカルマルチキャストルータに非常に類似した動作を行なう。一般的に、公衆陸上移動通信網（ＰＬＭＮ）の外部ローカルマルチキャストルータが、ＧＧＳＮの代わりに使用されてもよい。
【００６８】
また、ＧＧＳＮは、コアネットワークの範囲に事前に設定されたマルチキャストグループを事前に確立する。実際には、ＧＧＳＮとトランスポートレイヤ上のＳＧＳＮのような全ての対象ノードとの間に、ソースベースのマルチキャストツリーが生成される。データをＳＧＳＮへと配信するには、ＩＰマルチキャストを使用するのが好ましい。データが配信されると、ＳＧＳＮはパケットを複製してこれを関係する移動局へと転送する。本発明がＳＧＳＮとこれに接続するＲＮＣとの間のインタフェース上で使用されるような場合には、ＲＮＣがパケットを複製する。上述のマルチキャストグループは、いわゆる事前設定されたトランスポートレベルのマルチキャストグループ（ＴＬＭＧ）と呼ばれる。
【００６９】
本発明の基本的概念は図５を参照して開示される。
【００７０】
図５は、異なる構成のコネクションを介して４台のＳＧＳＮと通信を行なうＧＧＳＮを示している。ＧＧＳＮとＳＧＳＮとの間では、事前に設定されたＴＬＭＧが事前に確立される。各点線は、異なる事前設定のＴＬＭＧを示している。ＴＬＭＧはコアネットワークの範囲を有する。すなわち、ＳＧＳＮからＧＧＳＮまでの範囲である。ＴＬＭＧは、Ｇｉインタフェース上で受信されたマルチキャストトラフィックを、Ｇｎインタフェースを介してＳＧＳＮへと転送する際に使用される。ＴＬＭＧは、例えば、異なるサービス品質（ＱｏＳ）パラメータなどの異なるサービスクラスに基づいて、任意に多重化された複数のマルチキャストストリームを転送することができる。ＳＧＳＮにおいて、ストリームは必要に応じて分離されて複製される。例えば、ＳＧＳＮとＭＳとの間ではユニキャスト伝送が使用される。ＴＬＭＧは事前に確立されているので、ＴＬＭＧの確立によりＧＧＳＮと対象のＳＧＳＮとの間におけるマルチキャストグループの登録がさらに遅延することはない。
【００７１】
事前に設定されたＴＬＭＧの概念は、運用・保守又はネットワークエンティティ間の設定メッセージにも使用することができる。
【００７２】
以下の説明では、本発明の好適な実施例を示す。この実施例では、Ｇｎインタフェース上でのマルチキャスティングを説明する。これは、ＧＧＳＮとＳＧＳＮとの間でのマルチキャスティングを意味する。トランスポートレベルのマルチキャストを、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）又はセッション開始プロトコル（ＳＩＰ）などをベースとした他のポイントツーポイントネットワークに適用する際にも、同様のメカニズムを使用することができる。さらに、ＧＧＳＮと、別のＰＬＭＮに配置されたＳＧＳＮとの間のＧｐインタフェースにも同様のメカニズムを適用可能である。
【００７３】
ＳＧＳＮは、ＩＧＭＰを使用して特定のＴＬＭＧに関心があることを、対応するＧＧＳＮに通知する。別の方法では、ＧＧＳＮが、ＴＬＭＧに接続されるＳＧＳＮを管理する。ＧＧＳＮ及びＳＧＳＮの少なくとも一方において実施可能なこの管理処理は、管理インタフェースにより制御される。管理インタフェースは、例えば、ネットワーク管理で知られている運用・保守（Ｏ＆Ｍ）インタフェースであっても良い。オペレータは、例えば、ＳＧＳＮの構成を設定することができ、運用開始後、事前に設定されたＴＬＭＧをＧＧＳＮが事前に確立する。このときの事前設定はＳＧＳＮの必要条件に対応している。ＳＧＳＮの事前設定に対する変更は、管理インタフェースによっても実施することができる。事前に設定されたＴＬＭＧは、ルーティングプロトコルにより確立することができる。マルチキャスト・ルーティング・プロトコルは、ルートとしてのＧＧＳＮ及びリーフとしてのＳＧＳＮを有するマルチキャスト配信ツリーを構築するのに使用される。
【００７４】
ＵＭＴＳネットワークでは、会話型サービス又はストリーミングサービスなど、様々なサービスクラスが使用されるため、ＴＬＭＧはサービスクラスごとに作成される。マルチキャスト・ルーティング・プロトコルは、対応するマルチキャスト配信ツリーを構築する際に必要とされるサービス品質（ＱｏＳ）を考慮する。負荷スケジューリング手段を提供するため、サービスクラスごとに複数のＴＬＭＧを作成することもできる。
【００７５】
ＴＬＭＧは、管理インタフェースを介して差別化サービスコードポイント又はサービスタイプ（ＴｏＳ）の設定を使用するように事前に設定することができる。これは、ＵＭＴＳベアラクラスと関連付けられ、対応するＩＧＭＰメッセージのルーティング及びマルチキャスト配信ツリーの構築に使用される。
【００７６】
結果として、図６に示したように、ＧＧＳＮとこれに接続された全てのＳＧＳＮとの間に、複数のサービスクラスベースマルチキャスト配信ツリーが作成される。
【００７７】
図６は、ＱｏＳルーティングに基づく３つの異なるマルチキャスト配信ツリーを示している。図６では、ＧＧＳＮとＳＧＳＮとの間に異なる点線を描くことで示されている。ツリー構造が異なっているのは、ツリーの構築の際に、ＱｏＳメトリクス又はサービスクラスが考慮されるためである。各リンクでは、複数のマルチキャストグループが多重化されていても良い。これは、複数のマルチキャストグループがＴＬＭＧにより達成される同じＱｏＳ必要条件を有する限り、同じＴＬＭＧで転送されることを意味する。図６では、マルチキャストデータストリームＭＣ１−ｄａｔａ及びＭＣ２−ｄａｔａにより示される。これらのデータストリームは、同じ事前設定のＴＬＭＧ上で多重化される。これは、同じＴＬＭＧアドレス、すなわち、ＴＬＭＧ１アドレスにより示される。
【００７８】
図７は、後述のシグナリングシナリオで使用されるデータ構造を示している。一般的に、データは任意の方法で集中化又は分散化することができ、異なるネットワークエンティティ間の情報転送はそれに合わせて変更される。
【００７９】
図７は、ノードＳＧＳＮ及びノードＧＧＳＮを実際のエントリと共に示している。ＧＧＳＮは、現在６つのＴＬＭＧである、ｔｌｍｇ１からｔｌｍｇ６を有する。ＴＬＭＧは、例えば、サービスクラス欄に列挙されたストリーミング又は会話型などのサービスクラスに割り当てられる。異なるｔｌｍｇによってもサービスクラスをサポートすることができるので、ＴＬＭＧとサービスクラスとの組み合わせが異なってくる場合もある。以下の説明では、これをＴＬＭＧ／サービスクラスの組み合わせと呼ぶ。ＭＣ−ａｄｄｒｅｓｓ欄は、さらに別のネットワークにおけるマルチキャストグループのマルチキャストアドレスｍｃ１からｍｃ１０を含んでいる。このグループはある特定のｔｌｍｇと関連付けられている。例えば、マルチキャストアドレスｍｃ１及びｍｃ２がｔｌｍｇ１に割り当てられる。これは、マルチキャストアドレスｍｃ１及びｍｃ２を有するマルチキャストデータストリームがｔｌｍｇ１上で多重化されることを意味する。また、ユーザ数は＃ＭＳｅｓ欄において管理され、マルチキャストグループごとのユーザ数又はＴＬＭＧごとの適正数が監視される。以下の説明において、この関係はマルチキャストグループ／ＴＬＭＧとして略される。ＳＧＳＮの変更又はＰＤＰコンテキストの削除する際に、あるマルチキャストグループ／ＴＬＭＧにユーザが所属するか否かを判断するために、ＧＧＳＮはＴＬＭＧごとのユーザの情報を格納しても良い。別の方法では、例えば、１以上のマルチキャストグループに登録したユーザについてのＰＤＰコンテキストに対するＴＬＭＧマルチキャストアドレスをＧＧＳＮ識別情報に格納する。ユーザは、複数のアクティブなＰＤＰコンテキストを有し、このＰＤＰコンテキストの各々を、１以上のマルチキャストグループに登録してもよい。これは、ユーザが登録されたマルチキャストグループのために、追加の識別子を付すことにより、ＰＤＰコンテキストデータを拡張できることを意味する。ＰＤＰコンテキスト活動（アクティブ）化は、外部のＩＰネットワークにログオンするようなものである。この目的で移動加入者ＩＤがＩＰアドレスと関連付けられる。以下の説明において、ＰＤＰコンテキストの活動化中は、ＴＩＤで識別されるＩＤを有するトンネルが、ＰＤＰコンテキストのために、ＳＧＳＮとＧＧＳＮとの間に作成される。ＧＴＰがＰＤＰコンテキスト活動化中に使用される場合、ＧＴＰトンネルが確立される。この手順の間、サービス品質（ＱｏＳ）のネゴシエーションがＭＳとＳＧＳＮ／ＧＧＳＮとの間で実行される。
【００８０】
ＳＧＳＮは、同様のエントリをＧＧＳＮ、ＴＬＭＧ、Ｓｅｒｖｉｃｅ Ｃｌａｓｓ、ＭＣ−Ａｄｄｒｅｓｓ及び＃ＭＳｅｓとして管理する。マルチキャストデータストリームを区別し、ストリームの分離処理を実行するには、ＳＧＳＮにおけるマルチキャストアドレス及びそのＴＬＭＧとの関係を管理する必要がある。ＳＧＳＮの＃ＭＳｅｓ欄には、マルチキャストデータを特定の移動局に送信するために、ｔｌｍｇに所属するユーザの一覧が含まれている。
【００８１】
以下の説明において、サービスクラスの必要条件に従って事前に設定されるＴＬＭＧを、サービスクラスベースＴＬＭＧと呼ぶことにする。サービスクラスベースＴＬＭＧは、ＧＧＳＮ又は対応するＳＧＳＮにおいて管理されてもよい。ＴＬＭＧの設定がＧＧＳＮにおいて行なわれる場合、ＴＬＭＧ／サービスクラスの組み合わせが管理される。全てのＳＧＳＮがＴＬＭＧの一部である必要はない。これは、例えば、ＳＧＳＮがマルチキャストグループに登録したユーザを持たないこともあるからである。この場合、ＴＬＭＧからＳＧＳＮを削除すると決定してもよい。このため、登録されたＳＧＳＮはＧＧＳＮのＴＬＭＧの一部として管理されなければならない。必要に応じて、ＧＧＳＮは、ＴＬＭＧによってサービスを提供される少なくとも１つのマルチキャストグループメンバを抱えているＳＧＳＮの数をカウントするためのカウンタをＴＬＭＧごとに含んでもよい。ＴＬＭＧを介するマルチキャスティングが効率的か否かを、マルチキャストデータを受信して決定する際に、このＳＧＳＮの数を考慮に入れてもよい。これは、グループメンバを有するＳＧＳＮの数と、グループメンバを持たず、かつマルチキャストトラフィックを破棄するための追加処理を行なう必要があるＳＧＳＮの数との間の関係によって決まる。ＴＬＭＧに接続されるもののマルチキャストグループメンバを持たないときには、ＳＧＳＮはマルチキャストトラフィックを受信する。ＳＧＳＮはマルチキャストデータを転送することが可能なリーフを持たないため、このデータを破棄すべきである。
【００８２】
サービスクラスベースＴＬＭＧが各ＳＧＳＮにおいて管理される場合、ＳＧＳＮがその一部を形成すべきＴＬＭＧを、ＴＬＭＧ／サービスクラスの組み合わせに反映される。ＴＬＭＧ／サービスクラスの組み合わせがＧＧＳＮにおいて設定構築される場合は、ＳＧＳＮにおいてサービスクラスを省略することができる。
【００８３】
全てのＴＬＭＧサービスクラスの組み合わせについて、全てのＳＧＳＮが登録しているとは限らない場合、ＧＧＳＮはＴＬＭＧ／サービスクラスの組み合わせごとに登録されているＳＧＳＮの情報を監視しなければならない。ＳＧＳＮはＴＬＭＧの一部ではないため、この情報は、どのＳＧＳＮが、対応するＴＬＭＧによってマルチキャストトラフィックを受信するか及びどのＳＧＳＮが追加のユニキャスト伝送コネクションを必要とするかを判定するために必要となる。これは、全てのＳＧＳＮについての登録処理が完了していない状態で、マルチキャストストリームが到着したときに持て起用可能である。
【００８４】
以下の説明において、本発明の好適な実施例を示す。この実施例では、サービスクラスベースＴＬＭＧの確立処理と解放処理を説明する。図８及び図９に基づいて説明を行なう。図８及び図９は、ＧＧＳＮと２台のＳＧＳＮ、すなわち、ＳＧＳＮ１及びＳＧＳＮ２との間で送信されるメッセージを時系列的に示している。矢印は送信されるメッセージを示している。矢印の上方にメッセージの名称が示され、矢印の下方にメッセージにより搬送されるパラメータが列挙される。図８及び図９では、関連するパラメータのみが示される。右側の枠はメッセージ受信後にノードで実行されるアクションを示している。各記号の適切な意味は、以降の図面にも適用される。
【００８５】
図８のシーケンスは、設定がＧＧＳＮで行なわれる場合のサービスクラスベースＴＬＭＧ確立処理を示している。ＧＧＳＮは、ＴＬＭＧマルチキャストアドレスＴＬＭＧ−ＭＣＡｄｄｒを有するＴＬＭＧ登録要求をＳＧＳＮ１及びＳＧＳＮ２に送信する。このアドレスはＴＬＭＧの割当てマルチキャストアドレスである。ＱｏＳパラメータもこのメッセージに含まれる。既に説明したように、制御情報の交換にＧＴＰプロトコルを使用することができる。このためには、新規のメッセージによって、プロトコルを拡張する必要がある。これは、新規ＧＴＰというプリフィックスにより記述される。新規のメッセージをＧＴＰに導入するか、あるいは、新規の追加情報でもって既存のメッセージを改訂すればよい。ＩＧＭＰプロトコルを使用するＳＧＳＮ応答は、メンバシップ報告メッセージを伴う。
【００８６】
対応する各ＳＧＳＮにおける設定が分散型である場合、ＴＬＭＧ登録要求メッセージは省略される。ＧＧＳＮ及びＳＧＳＮにおいて設定を使用することも可能である。この場合、対応するシーケンスを同時に実行することもできる。また、図８のシグナリングを部分的に同時に実行することもできる。
【００８７】
どのＳＧＳＮがＴＬＭＧをサポートすることでＴＬＭＧの一部となっているかをＧＧＳＮが把握するために、必要に応じて、ＴＬＭＧ要求メッセージの肯定応答又は否定応答を使用してもよい。適用する多重化手順など、ＴＬＭＧ関連設定パラメータを取り決める際にも、ＴＬＭＧ登録要求手順を使用することができる。ＰＰＰネゴシエーションにおいて使用されるような汎用ネゴシエーションメカニズムを適用して、ＴＬＭＧに使用される共通の設定パラメータ群について同意することができる。ＳＧＳＮはＩＧＭＰメンバシップ報告メッセージを使用してサービスクラスベースＴＬＭＧに登録し、ＴＬＭＧ配信ツリーの一部を形成することができる。メンバシップ報告メッセージについては、必要なＱｏＳを考慮に入れてルーティングする。
【００８８】
ＴＬＭＧにおけるＭＣ−ｔｒａｆｆｉｃの多重化は様々な方法を用いて実行することができる。基本的に全ての多重化アルゴリズムを適用することができよう。多重化がネットワークにおいて共通でない場合、すなわち、全てのＳＧＳＮが必ずしも同じ多重化をサポートしていない場合、ＧＧＳＮとＳＧＳＮとの間で適用される多重化メカニズムのネゴシエーションが必要となるかもしれない。必要に応じて、ＧＧＳＮは異なるＳＧＳＮの多重化機能を備えるように設定される。言うまでもなく、ＴＬＭＧごとに１つの多重化処理の手法が使用されるべきである。幾つかの多重化メカニズムが適用可能な場合、ＴＬＭＧは、対応するＳＧＳＮにより適用・サポートされている多重化の種別をベースとすることができる。これは、事前に設定されたＴＬＭＧの確立処理中に考慮される必要がある。例えば、ＳＧＳＮが特定の種別の多重化をサポートしない場合、ＴＬＭＧ全体に対して多重化が変更されるか、専用のＴＬＭＧが確立されるか、あるいは、ＳＧＳＮがＴＬＭＧから除外され、ＳＧＳＮのユーザに対してユニキャストセッションが使用されることになろう。また、ＴＬＭＧを確立する前に、異なる設定をクエリーしてネゴシエートするために、シグナリングシーケンスを使用することができる。専用のＴＬＭＧとは、事前に設定され、そして事前に確立されたＴＬＭＧを考慮せずにユーザ要求に応じて確立されたＴＬＭＧを意味する。
【００８９】
図９を参照する以下の説明では、設定がＧＧＳＮで行なわれる場合におけるサービスクラスベースＴＬＭＧの解放処理を示している。この場合、ＧＧＳＮはＴＬＭＧ解放要求を対応するＳＧＳＮ、すなわち、ＳＧＳＮ１及びＳＧＳＮ２に送信することによって解放処理を開始する。対応するＳＧＳＮにおける設定が分散型である場合、ＴＬＭＧ解放要求メッセージは省略される。ＧＧＳＮ及びＳＧＳＮにおいて設定を同時に使用することも可能である。どのＳＧＳＮがＴＬＭＧから削除されたかをＧＧＳＮが把握するために、必要に応じて、ＴＬＭＧ解放メッセージの肯定応答及び否定応答を使用してもよい。
【００９０】
ＳＧＳＮは、ＴＬＭＧ配信ツリーから除外されるようにするため、ＩＧＭＰ脱退メッセージを使用してサービスクラスベースＴＬＭＧへの登録を解除する。ＩＧＭＰバージョン１には、明示的な脱退メッセージが存在しないため、グループから脱退するための適正なメカニズムが使用される。標準ＩＧＭＰメンバシップクエリーメッセージとは対照的に、ＳＧＳＮは以降の定期的なメッセージ送信を行なわないことによってＴＬＭＧから脱退することもできる。ＩＧＭＰバージョン１及びバージョン２をサポートするために、ＧＧＳＮはオプションのテーブルを保持することができる。このテーブルは、ＳＧＳＮがサポートするＩＧＭＰバージョンを反映するものである。
【００９１】
ＳＧＳＮをＴＬＭＧから削除した後、マルチキャスト配信ツリーが更新される。これは、マルチキャストルーティングプロトコルにより行なうことができる。
【００９２】
別の実施例では、ＧＧＳＮが登録手順を開始する場合、あらゆる可能なＴＬＭＧ／サービスクラス組み合わせを、ＴＬＭＧ登録要求メッセージで示してもよい。ＳＧＳＮは、登録したいＴＬＭＧに関して個別のＩＧＭＰメンバシップ報告メッセージをＧＧＳＮに送信する。また、特定の又は全てのＴＬＭＧについて登録するよう、ＧＧＳＮがＳＧＳＮに命令してもよい。
【００９３】
ＧＧＳＮは、ＰＬＭＮのマルチキャストグループメンバの総数のみならずＧＧＳＮに論理的に接続されるＳＧＳＮの台数に基づいて、特定のマルチキャストグループに対してＴＬＭＧが適用されるか否かを決定してもよい。このような決定は、ユーザがマルチキャストグループに登録する又はグループへの登録を解除するときには、いつでも進行中のマルチキャストセッション中に変更できるという意味において動的であってもよい。
【００９４】
以下の説明では、本発明の好適な実施例が示される。この実施例では、マルチキャストグループの登録処理を説明する。図１０に基づいて説明を行なう。
【００９５】
ＰＤＰコンテキストの活動化処理の後、ユーザはＩＧＭＰメンバシップ報告を使用することで、ＧＧＳＮ内の特定のマルチキャストグループに登録を行なう。ＧＧＳＮはローカルマルチキャストルータとして機能する。ＩＧＭＰ及びＭＬＤにおいて指定されるローカルマルチキャストルータとは異なり、ＧＧＳＮはアクティブなＰＤＰコンテキストを有する全てのユーザに対してメンバシップクエリーを送信する訳ではない。これを送信すれば、貴重な無線リソースを不必要に浪費することになるであろう。その代わりに、ユーザは単独でマルチキャストグループへの参加を開始する。これは、メンバシップクエリーメッセージにより要請されることなく、ユーザがメンバシップ報告メッセージにより自身のメンバシップを報告することを意味する。ＩＧＭＰの規定では、マルチキャストグループごとに１つのメンバだけがメンバシップを報告する。このため、ローカルマルチキャストルータには、対応マルチキャストグループの少なくとも１つのメンバがローカルネットワークに接続されていることしか分からない。ローカルマルチキャストルータは、いくつのメンバが接続しているかも、これらのメンバの身元も把握してはいない。しかし、各マルチキャストグループメンバが上述のように自身のメンバシップを報告する場合には、ＧＧＳＮ又は他のローカルマルチキャストルータは、マルチキャストグループごとのマルチキャストグループメンバの数のみならず、全てのグループメンバの身元についても情報を取得している。この情報は、効率化、課金、又は統計的な目的で使用することができる。また、ユーザ数と、サポートされるマルチキャストグループの一部であるＳＧＳＮの情報とを格納することも可能であり、ＧＧＳＮは、必要に応じて、対応するＳＧＳＮに情報を要求する。マルチキャストグループメンバを有する対応ＳＧＳＮの情報が格納されていない場合、ＴＬＭＧ自体を使用して全ての対象ＳＧＳＮに全メンバシップ要求をマルチキャストしてもよい。ＧＧＳＮは、グループメンバ数を考慮に入れ、ＴＬＭＧが効率的か否か、あるいは、複製されたユニキャストセッションを代わりに使用することが許容可能か否かを決定することができる。ＧＧＳＮはＩＧＭＰプロトコルを終了し、ＭＳのマルチキャストグループメンバシップについての情報を格納する。
【００９６】
必要に応じて、既存メッセージのうちの１つがメンバシップクエリーを含むように改訂されてもよい。これは、例えば、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GRPS), Service Description, Stage 2 (Release 1999)に規定されるように、ルータ通知メッセージに適用されてもよい。
【００９７】
ＩＧＭＰメンバシップ報告の受信後、ＧＧＳＮは必要に応じて検証を行ない、ユーザをマルチキャストグループに登録してもよいか否かを判定する。セキュリティチェックによりユーザのマルチキャストグループへの参加が許可されない可能性もあるし、グループの特性上、オペレータがマルチキャストグループ登録を許可しない可能性もあるし、あるいは、許容されたマルチキャストグループメンバが最大数に到達している可能性もある。ＧＧＳＮにおいて幾つかの他のチェック処理が実行されてもよい。判定結果が肯定的でない場合、ＧＧＳＮはメンバシップ報告拒絶メッセージをユーザに返信し、後述するシーケンスを実行しない。必要に応じて、ＧＧＳＮはメンバシップ報告拒絶メッセージの代わりにＩＣＭＰエラーメッセージをユーザに返信することもできる。
【００９８】
ホストが、閉じたグループの一部であるか否かを判定できるようにするために、ＧＧＳＮにおいて管理が行なわれてもよい。あるいは、ＧＧＳＮがマルチキャストグループを管理するサーバ又はデータベースへの外部インタフェースを有することもできる。
【００９９】
ＧＧＳＮは、マルチキャストグループに登録された移動局を有していることを、対応するＳＧＳＮに通知する。新規のＧＴＰメッセージが、ＳＧＳＮメンバシップ報告要求のために使用される。この目的で拡張ＰＤＵ通知メッセージを使用することも可能である。ＰＤＵ通知はＧＴＰ通知メッセージであり、例えば、TS 29.060. 3GPP TS 29.060 V.4.0.0 (2001 03) 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GRPS); GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface (Release 4)に規定されている。
【０１００】
ＴＬＭＧ確立手順の後、図８を参照して説明したように、複数の事前に設定されたＴＬＭＧがコアネットワークにおいて確立される。このコアネットワークでは、ＧＧＳＮがルートであり、ＳＧＳＮがツリーのリーフである。コアネットワークのＴＬＭＧを使用して外部のマルチキャストトラフィックがユーザに転送される。複数のマルチキャストグループが１つのＴＬＭＧ上へと多重化される場合、分離識別子が必要である。後述の図面では、Ｇｉインタフェースを介して受信される外部のマルチキャストグループのマルチキャストアドレスＭｃＡｄｄｒが、ＳＧＳＮでの分離処理に使用される。したがって、ＭｃＡｄｄｒがＳＧＳＮメンバシップ報告要求メッセージの形態でパラメータとして送信される。ＴＬＭＧについて多重化メカニズムが使用されない場合、マルチキャストグループのうちの１つだけがＴＬＭＧにマップされる。また、ＴＬＭＧのマルチキャストＩＰアドレスであるＴＬＭＧ−ＭｃＡｄｄｒが、新規のＧＴＰメッセージＳＧＳＮメンバシップ報告要求を伴って送信される。ＴＬＭＧ−ＭＣ Ａｄｄｒｅｓｓの使用は任意であり、メッセージにおける使用も任意である。また、ユーザのホストＩＤ、すなわち、マルチキャストグループに登録されたＭＳ−ＨｏｓｔＩＤはパラメータとしてこのメッセージを伴って送信される。
【０１０１】
実際、マルチキャスト・グループ・トラフィックにおいて、ＧＧＳＮは、ＰＤＰコンテキストの活動化中に、ＳＧＳＮによって既に確立されているＭＳ用のトンネルを無視し、代わりに事前に設定されたマルチキャスト配信ツリーを使用する。
【０１０２】
ＳＧＳＮメンバシップ報告要求メッセージの受信後、ＳＧＳＮはマルチキャストグループＭＣメンバシップ検証を行なう。特に、任意又は特定のマルチキャストグループに移動局を登録可能であるか否かを判定するために、ＳＧＳＮが加入チェック又は課金口座チェックを行なうことができることを意味する。検証の結果は、ＳＧＳＮメンバシップ報告結果メッセージに含まれる。検証結果が「否」の場合、ＳＧＳＮはＳＧＳＮメンバシップ報告結果メッセージをＧＧＳＮへと返信する。結果が否の場合には、マルチキャスト検証が失敗し、移動局がマルチキャストグループに参加すべきでないことを示す。原因の表示を伴うことができる。検証結果が「可」の場合、メッセージはＧＧＳＮに対して肯定的な結果を示す。さらに、ＳＧＳＮは、データを複製してマルチキャストデータストリームの受信時に、対応するホストに転送できるよう、Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓをユーザに対する既存のＰＤＰコンテキスト情報に加えることによって、ＭＣＡｄｄｒとＭＳ−ＨｏｓｔＩＤとの間の関係を記憶する。必要に応じて、使用されるＴＬＭＧのＴＬＭＧ−Ａｄｄｒｅｓｓも記憶される。
【０１０３】
ＴＬＭＧは事前に確立されているので、ＴＬＭＧのメンバであるＳＧＳＮの動的な更新及び検証は省略されても良い。
【０１０４】
ＳＧＳＮメンバシップ報告結果を受信すると、ＧＧＳＮはメンバシップ報告受諾又はメンバシップ報告拒絶を移動局へと返信する。このメッセージは、検証結果によっては原因の表示を含む。また、ＧＧＳＮは検証結果が肯定的の場合には何も返信せず、検証結果が否定的の場合にはＩＧＭＰエラーメッセージを返信しても良い。
【０１０５】
ＳＧＳＮメンバシップ報告結果が肯定的の場合、マルチキャストグループのユーザ数のカウンタが増分され、及び／又は、ＭＳ−ＨｏｓｔＩＤがマルチキャストグループ又はＴＬＭＧに追加される。
【０１０６】
ＧＧＳＮは、例えば、ＩＧＭＰメンバシップ報告を送信することによって、Ｇｉインタフェース上のバックボーンネットワークを介し、マルチキャストメンバシップの伝播の管理を行なう。隣接するルータへのメンバシップ伝播では、ＰＬＭＮなどのローカルネットワークの対応するマルチキャストグループ内にマルチキャストデータの受信を希望するメンバが少なくとも１つ存在することを通知するだけで良い。このため、ＰＬＭＮ内の第１のマルチキャストグループメンバに対してのみ、この伝播が必要とされる。マルチキャストグループがＧＧＳＮにおいて未知の場合、ＧＧＳＮはＧｉインタフェースを介してメンバシップ報告メッセージを次のマルチキャストルータへと伝播する。これにより、マルチキャストグループへと参加できるようになり、マルチキャストトラフィックを受信してマルチキャストグループの一部であるＰＬＭＮのＭＳｅｓへと当該トラフィックを転送できるようになる。ＧＧＳＮは、マルチキャストグループのユーザ数のカウンタ又はＭＳ−ＨｏｓｔＩＤの実際の数によりＧｉインタフェース上のメッセージを伝播すべきか否かを認識する。
【０１０７】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１１を参照してマルチキャストグループ登録解除処理及びＴＬＭＧの解放処理を説明する。
【０１０８】
先に説明したように、アクティブなＰＤＰコンテキストを有する全てのユーザには、定期的なメンバシップクエリーメッセージは送信されない。ＩＧＭＰバージョン１によれば、ローカルマルチキャストルータは、定期的にメンバシップクエリーメッセージをマルチキャストすることによって、ＬＡＮ上のマルチキャストグループにメンバが残存するか否かを判定する。ＩＧＭＰバージョン２では、脱退するメンバの待ち時間を削減するために脱退メッセージが定義されている。
【０１０９】
図１１において、移動局からのＩＧＭＰ脱退メッセージの受信時に、ＧＧＳＮは基本的なチェックを実行する。例えば、ＧＧＳＮは、移動局がマルチキャストグループの一部であったか否かをチェックする。ＧＧＳＮは新規のＧＴＰメッセージＳＧＳＮメンバシップ要求解放をＳＧＳＮへと送信し、移動局に対するメンバシップ解放を要求する。このメッセージは、パラメータとしてＴＬＭＧ ＭＣＡｄｄｒと移動局のアドレスＭＳ−ＨｏｓｔＩＤとを搬送する。ＳＧＳＮは、オプションの肯定メッセージＳＧＳＮメンバシップ解放ＡＣＫをＧＧＳＮへと返信することによって解放を確認し、対応するＴＬＭＧのリストから移動局を削除する。また、ＧＧＳＮは対応するマルチキャストアドレスのリストから移動局を削除するか、あるいは、対応するカウンタを減分する。
【０１１０】
必要に応じて、ＧＧＳＮは、ＳＧＳＮに係るマルチキャストグループ内のメンバの数が、ＳＧＳＮに対してマルチキャスト配信ツリーを使用するのに妥当ではなく、ＳＧＳＮのＴＬＭＧへの登録を解除すべきであると決定してもよい。これは、ＧＧＳＮからＳＧＳＮへと向かうオプションの情報要素Ａｃｔｉｏｎにより示される。パラメータＡｃｔｉｏｎはオプションである。データ配信を最適化するために使用されるべきである。このパラメータを使用することによって、ＧＧＳＮが過負荷の状況にあってもメッセージを使用することができる。
【０１１１】
ＧＧＳＮが、ＰＬＭＮの最後のマルチキャストグループメンバがマルチキャストグループへの登録を解除したと判定する場合、この情報はＧｉインタフェースを介して隣接するルータへと伝播される。ＩＧＭＰバージョン２又はそれ以降のバージョンが使用される場合、ＧＧＳＮはＩＧＭＰ脱退メッセージを送信する。バージョン２又はそれ以降のバージョンが使用されない場合、ＧＧＳＮはＧｉインタフェース上のマルチキャストグループメンバシップの更新処理を行なわない。
【０１１２】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１２を参照してＰＤＰコンテキストの非活動化処理を説明する。
【０１１３】
ＳＧＳＮ及びＧＧＳＮの少なくとも一方が、ＰＤＰコンテキストの非活動化処理を開始する。ＰＤＰコンテキストの非活動化には、２つのシグナリングメッセージ、すなわち、ＰＤＰコンテキスト削除要求及びＰＤＰコンテキスト削除応答が含まれる。非活動化を開始するノードは、ＰＤＰコンテキスト削除要求を送信し、応答としてＰＤＰコンテキスト削除応答を受信する。この手順は、3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)及び3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に詳細に記載されている。
【０１１４】
ＰＤＰコンテキスト非活動化処理の実行後、マルチキャストグループの登録解除処理と同様の、対応するシグナリングメッセージを伴う手順が適用される。ＳＧＳＮは移動局が１以上のＴＬＭＧの一部であったか否かをチェックする。チェック結果に従って、ＴＬＭＧ又は複数の対応するＴＬＭＧから移動局が削除される。その対応する１つ又は複数のＴＬＭＧにとって最後の移動局であったか否かによって、ＳＧＳＮはＴＬＭＧへの登録を解除することもある。
【０１１５】
マルチキャストグループ又はＴＬＭＧごと（いわゆるＭＣ−ｇｒｏｕｐ／ＴＬＭＧ）に格納された全てのＭＳ−ＨｏｓｔＩＤを有する場合、移動局が１以上のマルチキャストグループの一部であるか否かを、ＧＧＳＮがチェックし、その結果に従って動作することもできる。全てのＭＳ−ＨｏｓｔＩＤを有しない場合、ＳＧＳＮは、ＭＳ−ＨｏｓｔＩＤ及びＭｕｌｔｉｃａｓｔＧｒｏｕｐ／ＴＬＭＧを指定する新規の情報要素により、ＰＤＰコンテキスト削除要求メッセージ又はＰＤＰコンテキスト削除応答メッセージの形態で、ＧＧＳＮに通知する。あるいは、ＳＧＳＮからＧＧＳＮへの通知には、ＳＧＳＮメンバシップ解放に関して図１２に示されるのと同様の情報要素を伴う新規のメッセージが使用される。このメッセージは、ＧＧＳＮがＭＣ−ｇｒｏｕｐ／ＴＬＭＧごとに格納されたＭＳ−ＨｏｓｔＩＤを有する場合に使用可能であろう。ＴＬＭＧは、ＳＧＳＮにおいても、ＳＧＳＮメンバシップ解放メッセージにおいても任意のものである。
【０１１６】
上述のようなＳＧＳＮメンバシップ解放メッセージ又はそれに類するメッセージの受信時に、前述のマルチキャストグループ登録解除シーケンスで説明したのと同様の処理が適用される。ＰＤＰコンテキストの非活動化の後、前述のＩＧＭＰ脱退メッセージを使用することによって、マルチキャストグループ登録解除と同様の処理が適用される。ＭＳが１つ以上のマルチキャストグループの一部であったか否かを、ＳＧＳＮがチェックする。グループの一部である場合、ＭＳはこの１以上のマルチキャストグループから削除される。
【０１１７】
以下の説明では、本発明の好適な実施例が示される。この実施例では、移動局が在圏ＳＧＳＮエリアを変更する場合の手順を説明する。
【０１１８】
移動局が在圏ＳＧＳＮを変更する場合、ＳＧＳＮ及びＧＧＳＮに格納されたマルチキャスティング情報は、それに従って変更しなければならない。ＴＬＭＧも更新する必要が生じるかもしれない。
【０１１９】
3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)及び3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に記載されているように、ＭＳはＧＰＲＳ位置情報登録処理（Attach）、ＳＧＳＮ間ルーティングエリア更新処理、又は在圏無線ネットワークサブシステム再配置処理によって、在圏ＳＧＳＮを変更することができる。
【０１２０】
ＧＰＲＳ位置情報登録は、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)及びセクション６．１３．２のthe Inter SGSN Inter System Changeを含む同文書のセクション６．９．１．２．２のthe Inter SGSN Routing Area Updateに記載されている。The Serving SRNS Relocationは同文献のセクション６．９．２．２．１において見出される。
【０１２１】
しかし、ＧＰＲＳ位置情報登録を実行するときには、移動局はマルチキャストグループに登録されないので、マルチキャスティングではこの手順を考慮する必要がない。ＰＤＰコンテキストの削除処理の実行によって、対応するマルチキャストグループへの移動局の登録は、既に解除されているからである。
【０１２２】
ＳＧＳＮ間ルーティングエリア更新処理又は在圏ＳＲＮＳ再配置処理の場合、新規のＳＧＳＮはＰＤＰコンテキスト更新要求をＧＧＳＮへと送信する。
【０１２３】
ＳＧＳＮがマルチキャストグループメンバに対して変更される場合、ＳＧＳＮ及びＧＧＳＮにおけるマルチキャストの管理に関して３つの基本的な代替方法がある。
【０１２４】
第１の代替方法では、上述のように、以前のＳＧＳＮに対するマルチキャストグループ登録解除及びＴＬＭＧ解放と、新規のＳＧＳＮ手順に対するマルチキャストグループ登録及びＴＬＭＧ確立とが組み合わされる。以下の説明は図１０に基づいて行なわれる。
【０１２５】
上述したＰＤＰコンテキストの非活動化処理と同様に、ＳＧＳＮは、改良されたＰＤＰコンテキスト更新メッセージシグナリングを用いて、移動局がマルチキャストグループの一部であることをＧＧＳＮに通知する必要があるかもしれない。このシーケンスにおいて、ＧＧＳＮはＴＬＭＧの識別子についての通知を受信しなければならない。以前のＳＧＳＮ及び新規のＳＧＳＮに対して変さらについて通知するのはＧＧＳＮの機能である。以前のＳＧＳＮとは、移動局が登録されていたＳＧＳＮを意味し、新規のＳＧＳＮは移動局が現在処理されているＳＧＳＮである。以前のＳＧＳＮは、ＳＧＳＮメンバシップ解放要求メッセージにより通知される。処理担当となるＳＧＳＮの変さらについての確認応答として、以前のＳＧＳＮがＳＧＳＮメンバシップ解放Ａｃｋを送信する。以前のＳＧＳＮが最後の移動局を解放した場合、ＩＧＭＰ脱退メッセージが送信される。
【０１２６】
新規のＳＧＳＮにおけるマルチキャストメンバシップ検証処理はオプションである。ＧＧＳＮは、ＳＧＳＮメンバシップ報告要求メッセージ中の追加の識別子を使用して、これらのチェックが行なわれるべきか否かを判定してもよい。チェックが行なわれない場合、ＳＧＳＮメンバシップ報告結果を送信することによって、ＧＧＳＮに確認応答を通知すれば良い。あるいは、信頼性の高い通信の場合には、ＧＧＳＮに全く報告しなくても良いだろう。追加のマルチキャストメンバシップ検証が実行される場合、ＧＧＳＮは否定的な結果を移動局へと送信しなければならないかもしれない。この場合、ＳＧＳＮはＴＬＭＧへの登録を解除する必要があるだろう。ＰＬＭＮはマルチキャストグループへの登録を解除しなければならないかもしれない。なお、これらのメッセージシーケンスは図１３において省略されている。
【０１２７】
第２の代替方法では、ＰＤＰコンテキスト更新処理の実行後にマルチキャスト情報メッセージを送信することによって、以前のＳＧＳＮから新規のＳＧＳＮへとマルチキャストグループ情報が直接的に転送される。これは図１４に開示される通りである。以前のＳＧＳＮは、ＳＧＳＮメンバシップ解放によって、ＧＧＳＮにおけるエントリの削除を開始する。続いて、ＩＧＭＰ脱退メッセージが送信される。ＳＧＳＮは必要に応じて検証処理を行なっても良く、その結果に応じて、ＳＧＳＮメンバシップ報告をＧＧＳＮへと送信するのを回避しても良い。この場合、拒絶メッセージを移動局に送信することを、ＳＧＳＮはＧＧＳＮに報告するであろう。従って、第２の方法でも、第１の方法と同じ原理を適用することができる。
【０１２８】
第３の代替方法では、マルチキャスト情報メッセージを以前のＳＧＳＮから受信した後で、ＧＧＳＮにおける以前のＳＧＳＮ及び新規のＳＧＳＮについてのマルチキャストエントリを更新するために、新規のＳＧＳＮが更新メッセージであるマルチキャストＳＧＳＮ変更情報をＧＧＳＮに送信する場合の簡単な解決法を開示している。このシグナリングメッセージの交換も図１５に示している。
【０１２９】
３つの方法の全てにおいて、以前のＳＧＳＮ及び新規のＳＧＳＮの双方に関して、マルチキャスト・ルーティング・プロトコルにより最終的にＴＬＭＧが更新される。
【０１３０】
第２の方法及び第３の方法では、以前のＳＧＳＮから新規のＳＧＳＮへのマルチキャスト情報転送は、新規のＳＧＳＮとＧＧＳＮとの間にＰＤＰコンテキスト更新を送信する前に行なわれても良い。ＰＤＰコンテキスト更新についてのメッセージ交換処理は、マルチキャスト情報を伴うように拡張されても良い。
【０１３１】
３つの方法の全てにおいて、新規のＳＧＳＮが実施した検査処理によって、マルチキャストグループメンバシップを受諾しないとなった場合には、追加のメッセージが移動局に送信されても良い。例えば、新規のＳＧＳＮがマルチキャストルーティングプロトコルをサポートしない、あるいは、マルチキャスト情報交換メッセージ又はマルチベンダ環境などの情報要素をサポートしない場合にこれが当てはまるかもしれない。ＭＳは、登録解除を行なうためにＩＧＭＰ脱退メッセージをＧＧＳＮに送信するように命令される。
【０１３２】
以下の説明では、ＴＬＭＧ上でのマルチキャスト・ストリーム・データの多重化を説明する。
【０１３３】
Ｇｉインタフェースに到着する全てのマルチキャスト・グループ・トラフィックに対して、限られた数のＴＬＭＧを使用することによって、マルチキャストストリームはコアネットワークにおいて暗黙的に多重化される。事前に設定されたＴＬＭＧ上でマルチキャストストリームを多重化するには幾つかの方法がある。説明される多重化手法は、ＴＬＭＧが事前設定でなく、必要に応じて確立される場合にも適用することができる。
【０１３４】
以下の説明では、多重化を実行する幾つかの方法が提示される。
【０１３５】
コアネットワークにおけるマルチキャスティングはＰＬＭＮ特有のマルチキャストアドレスに基づいているため、ＩＰパケットヘッダ中のオリジナルのマルチキャスト宛先アドレスは変換されるべきである。オリジナルのＩＰマルチキャストアドレスは、プライベート拡張ヘッダとしてＩＰパケットヘッダに加えられる。
【０１３６】
ＩＰｖ６ではこれが可能であり、ＩＰヘッダフィールドの次のヘッダとしてＩＰを指定することによって、追加のルーティングヘッダを加えることができる。このルーティングヘッダ中のＩＰアドレスもＩＰ−Ｍｕｌｔｉｃａｓｔアドレスである。これは、Ｇｉインタフェース上で受信した最初のＩＰマルチキャストアドレスであることを意味する。分離化処理は、宛先Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ又はＭｕｌｔｉｃａｓｔ Ｐｏｒｔに基づいて、ＳＧＳＮにおいて実行される。ＩＰヘッダ中のポート番号に基づいて、異なるアプリケーションを識別することができる。これは、同じ宛先アドレスに所属する、異なるアプリケーションに対して指定される複数のマルチキャストデータストリームを、同一のＴＬＭＧ上で多重化することができ、各ストリームの区別はポートアドレスにより行なわれることを意味する。このため、ＳＧＳＮは移動局ＩＤに対応するマルチキャストアドレス又はマルチキャストポートのテーブルを保持する必要がある。
【０１３７】
別の方法では、ＳＧＳＮにおいてマルチキャストストリームを分離するために、ＧＴＰトンネリングＩＤであるＴＩＤを使用することができる。この場合、Digital cellular Telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Point To Multipoint Multicast Service Description; Stage 2; GSM 03.61, 15th January 1997, Version 0.7.1に記載されているようなＧＴＰ−Ｕの拡張バージョンが使用される。ＳＧＳＮは、ＴＩＤと移動局ＩＤとの関連付けを記憶するテーブルを保持する必要がある。この方法が使用される場合、マルチキャストアドレスはＴＩＤにより置換される。マルチキャストアドレスの代わりとしてのＴＩＤを送信できるようにするためには、シグナリングシーケンスを改訂する必要があろう。
【０１３８】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１６を参照してマルチキャストデータ配信手順を説明する。
【０１３９】
図１６は、マルチキャストデータがＧＧＳＮで受信され、受信されたマルチキャストデータを、ＴＬＭＧを介してそれぞれ複数のグループメンバが接続されている２台のＳＧＳＮへと転送するシナリオを示している。
【０１４０】
複数のＴＬＭＧは、ＵＭＴＳサービスクラスごとに存在してもよいので、元のマルチキャストアドレスは、前述のようにＴＬＭＧを介してＳＧＳＮに転送されるマルチキャストストリーム内に搭載されて搬送されなければならない。この元のマルチキャストアドレスは、ＳＧＳＮ内の１つのＴＬＭＧ上に存在する、異なるマルチキャストフローを分離するために必要となる。ＧＧＳＮは、以下の基準のうち、１以上を考慮することによって特定のマルチキャストセッションに使用されるＴＬＭＧを判定する。例えば、ＩＰヘッダのサービス種別ビットなどに従って、Ｇｉインタフェース上で受信されるマルチキャストストリーム内で示されている必要なＱｏＳが考慮される。必要なＱｏＳは、ポリシー実行ポイント、ポリシー決定ポイント、又は呼状態制御機能（ＣＳＣＦ）など、外部のエンティティによっても通知することができる。さらに、デフォルト又は既知のマルチキャストアドレスに対する所要のサービスクラスの設定を考慮に入れてもよい。
【０１４１】
マルチキャストデータストリームを受信すると、ＧＧＳＮは、テーブル中でアプリケーション・レベル・マルチキャスト・アドレスに属するＴＬＭＧアドレスを検索する。この検索の際に、必要に応じてＱｏＳを考慮に入れる。ＧＧＳＮは、ＩＰ宛先アドレスをＴＬＭＧマルチキャストアドレスへと変更し、元のマルチキャストアドレスを拡張情報としてＩＰパケットヘッダへと加え、ＴＬＭＧの一部である全てのＳＧＳＮに対してデータをマルチキャストする。上述した他の多重化メカニズムの１つが使用される場合、元のＩＰマルチキャストアドレスのカプセル化は異なる方法で実行される。
【０１４２】
ＳＧＳＮにおいてＴＬＭＧマルチキャストデータを受信すると、このＳＧＳＮはＩＰ宛先アドレスフィールド又はＴＬＭＧで指定されるような元のＩＰマルチキャストアドレスを取り出し、テーブル検索のためにこれを使用して対応するマルチキャストグループメンバを識別する。ＩＰ宛先アドレスはこの元のマルチキャストアドレスへと戻される。ＳＧＳＮはデータを複製し、ユニキャスト伝送又はマルチキャスト技術を使用し、無線アクセスネットワークを介してデータを各移動局へと転送する。マルチキャストグループに対してグループメンバを持たない場合、ＳＧＳＮはマルチキャストデータを無視する。
【０１４３】
以下の説明では、各実施例が提示される。これらの実施例では、例えば、ＳＧＳＮのような在圏ノードがＴＬＭＧの一部となることを決定する。
【０１４４】
必要に応じて、ＳＧＳＮは、ＭＳｅｓに対して中継するマルチキャストデータパケットの個数と、破棄するマルチキャストデータパケットの個数とについての統計値を収集する。これは、ＳＧＳＮには対応するマルチキャストグループの一部である移動局が存在しないためである。多重化により得られるよりもマルチキャストトラフィックを破棄するためにより高い処理能力を必要とするので、ＳＧＳＮはこの情報に基づいてＴＬＭＧへの登録の解除を決定しても良い。ＧＧＳＮは、ＴＬＭＧの一部でないＳＧＳＮのリストを格納しなければならない。これらは、マルチキャストトラフィックを受信することはない。その代わりに、ＧＧＳＮ内のマルチキャストトラフィックを複製することによってサービスの提供を受け、これらのＳＧＳＮに対してユニキャスト伝送を使用する。
【０１４５】
マルチキャスト率の評価は、ＳＧＳＮがＴＬＭＧの一部となることを決定するための一例である。他の例としては、地理的な座標に基づくＴＬＭＧが挙げられる。これは、例えば、国又は都市の一部などの地理的エリアをカバーする全てのＳＧＳＮにまたがっているＴＬＭＧを意味する。このようなＴＬＭＧは、天気予報、交通情報、又は娯楽情報などの地理的座標に関連するマルチキャストサービスを提供するのに使用されてもよい。
【０１４６】
上述の事前に設定されたＴＬＭＧ及び対応するマルチキャスト配信ツリーを使用して、ＵＭＴＳ内でのブロードキャストサービスを実現することもできる。関係するノードのみならず全てのノードがブロードキャストコンテンツを受信するので、ネットワークレベルでのブロードキャスティングは避けるべきである。複数のサービスプロバイダにより使用されるマルチサービスバックボーンネットワークの場合、全てのノードがコンテンツを受信する事態は避けるべきである。
【０１４７】
専用のＴＬＭＧ登録セキュリティ手順は、各ノードがＴＬＭＧに登録可能である場合についての手順である。この場合、各ノードの登録には専用のセキュリティ手順が必要とされるであろう。事前に設定されたＴＬＭＧの場合、例えば、ＧＧＳＮで設定が実行されると、自動的に１回の動作でＴＬＭＧ全体の安全を保証することができる。
【０１４８】
事前に設定されたＴＬＭＧの概念により、ネットワークの専用のノード群へのマルチキャストサービス及びブロードキャストサービスの提供が可能になる。特に、Ｇｐインタフェースでは、設定、管理などの関連情報のブロードキャスティング又はマルチキャスティングは、ＴＬＭＧにより経済的に処理されるようにしてもよいだろう。
【０１４９】
ブロードキャストされるデータストリームごとに、１つの事前に設定されたＴＬＭＧが確立又は選択される。このＴＬＭＧはＧＧＳＮに接続される全てのＳＧＳＮを含む。
【０１５０】
本願の開示では、ＧＰＲＳ／ＵＭＴＳに対する解決法を説明する。しかしながら、ＲＴＳＰを有するポイント・ツー・マルチポイントストリーミング又はＳＩＰを有する会話型マルチメディアサービスに対して、マルチキャスト・トランスポート・グループを作成するために、同様のメカニズムを適用できることは理解されるべきである。
【０１５１】
本願に記載される解決法は、異なるネットワークエンティティ間での情報交換をカバーしている。データ記憶装置は様々な方法で分散させてもよく、同一又は異なる情報の搬送手段として他のメッセージが使用されてもよいことは理解されるべきである。
【０１５２】
上述のシグナリングシーケンスにおける各メッセージにおいて、コネクション指向のアプローチが使用されている場合には、一部の情報要素が省略されてもよい。さらに、例えば、ＧＴＰメッセージなど、幾つかの新しい専用メッセージの代わりに、付加的な作用を有する共通のメッセージが使用されてもよい。
【０１５３】
この報告におけるシグナリングシーケンスは、信頼性の高い伝送をベースとしている。信頼性の低い伝送の場合、シーケンスはそれに適合するように、すなわち、確認メッセージ又は肯定応答メッセージを加えるよう、変更されなければならないだろう。
【０１５４】
さらに、この発明でカバーされる解決法は、ＧＳＭ又はＵＭＴＳネットワークのパケット交換ドメインに焦点を当てている。一般的に、この考えは、ＧＴＰ、Ｌ２ＴＰ、ＩＰＳｅｃ、Ｍｏｂｉｌｅ ＩＰなどのトンネリングが使用される際に適用することができる。従って、本発明は、２つのＩＰレイヤ、すなわち、アプリケーションＩＰレイヤ及びトランスポートＩＰレイヤを有するネットワークに適用することができる。また、トランスポートレイヤがＡＴＭなどのマルチキャスト伝送をサポートする別の技術に基づく場合には、各メカニズムを適用することができる。
【図面の簡単な説明】
【０１５５】
【図１】図１は、ＵＭＴＳネットワーク、無線ネットワーク、及びＩＰマルチメディアサブシステムにおけるパケット交換ドメインを示す図である
【図２】図２は、本発明に係る基本的概念のネットワークの関連図である。
【図３】図３は、ＵＭＴＳユーザプレーン用のプロトコルスタックの概要を示す図である。
【図４】図４は、本発明の基本的概念のプロトコル関連図である。
【図５】図５は、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを示す本発明の基本的概念を示す図である。
【図６】図６は、事前に設定されたトランスポートレベルのマルチキャストグループトンネル上での多重化を示す本発明の基本的概念を示す図である。
【図７】図７は、本発明に係る各エントリの管理用のデータ構造を示す図である。
【図８】図８は、事前に設定されたＴＬＭＧ確立手順を示す図である。
【図９】図９は、事前に設定されたＴＬＭＧ解放手順を示す図である。
【図１０】図１０は、マルチキャストグループ登録手順を示す図である。
【図１１】図１１は、マルチキャストグループ登録解除手順を示す図である。
【図１２】図１２は、ＰＤＰコンテキストの非活動化を示す図である。
【図１３】図１３は、ＳＧＳＮを変更する手順を実行する第１の代替方法を示す図である。
【図１４】図１４は、ＳＧＳＮを変更する手順を実行する第２の代替方法を示す図である。
【図１５】図１５は、ＳＧＳＮを変更する手順を実行する第３の代替方法を示す図である。
【図１６】図１６は、マルチキャストデータ配信ツリーを示す図である。
【０００１】
本発明は、通信網においてマルチキャストを実行する方法、ネットワークノード、ルータ、在圏ノード、及びシステムに関する。
【０００２】
本願は、特に、ポイントツーポイントパケット交換通信ネットワークにおいて適用可能である。
【背景技術】
【０００３】
マルチキャスティングとは、同一のデータのコピー１部をあるアドレスに送信することで、発信元が複数の受信者にデータを配信できるようにするサービスである。マルチキャスティングでは、メッセージのコピー１部だけがネットワーク内のリンクを通過し、経路が分岐する地点で複数部のコピーが作成される。ネットワークの観点から見て、マルチキャストは全体的な帯域幅の使用量を大幅に削減する。これは、データがエンドシステムにおいてではなく、ネットワークの適切なポイントで複製されるためである。また、マルチキャストメッセージを送信するサーバは１つのセッションを管理するだけで良い。
【０００４】
これまで長年にわたりローカルエリアネットワークがマルチキャスティングをサポートしてきた。各ノードが共通の通信媒体を共有するようなネットワークでは、マルチキャスティングをサポートするのは容易である。特別なアドレスを指定されたパケットは、この通信媒体から複数のホストにより読み出すことができる。
【０００５】
マルチキャスティング機能をインターネットワークへと拡張するには、到着するデータパケットをどのように転送するかを動的に解決するためにネットワークの終端にルータを導入することが必要であろう。転送方法は、例えば、データパケットのヘッダに含まれるアドレス及びルータで管理されるルーティングテーブルから決定される。例えば、マルチキャストグループを示すアドレスを使用するためにマルチキャストアドレス指定を実行する可能性はほとんどない。
【０００６】
インターネットプロトコル（ＩＰ）ネットワークで使用されるマルチキャストは、ＩＰマルチキャストと呼ばれる。ＩＰマルチキャスト内では、マルチキャストセッショングループのメンバシップは動的である。これは、ホストが随時グループに参加してもグループから脱退しても良いことを意味する。ネットワーク上のホストが、特定のマルチキャストグループへの参加又はグループからの脱退を希望するか否かを表明できるようにするために、インターネットグループメッセージプロトコル（ＩＧＭＰ）と呼ばれるプロトコルが存在する。このプロトコルにより、システムは、現在どのホストがどのマルチキャストグループに所属しているのかを知ることができる。この情報は、マルチキャストルータが、どのマルチキャストデータパケットがどのインタフェースへと転送されるべきかを知るのに必要である。
【０００７】
ＩＧＭＰはＩＰレイヤの一部であり、ＩＧＭＰメッセージはＩＰデータパケットの形態で伝送される。ＩＧＭＰのバージョン１は、ＲＦＣ１１１２「Host extensions for IP multicasting」（S.E. Deering、１９８９年８月１日）に記載されている。ＲＦＣ２２３６「Internet Group Management Protocol, Version 2」（W. Fenner、１９９７年１１月）には、バージョン２が記載されている。ＩＧＭＰは、ＩＰバージョン４に対して開発されたものである。インターネットプロトコル（ＩＰ）バージョン６では、マルチキャスト受信者探索（ＭＬＤ）と呼ばれる同様のプロトコルがあり、ＩＧＭＰと同じ目的で使用される。ＭＬＤの第1バージョンについての説明は、ＲＦＣ２７１０「Multicast Listener Discovery (MLD) for IPv6」（S. Deering, W. Fenner, B. Haberman、１９９９年１０月）に記載されている。ＭＬＤで使用されるメッセージはＩＧＭＰメッセージに対応している。以下の説明ではＩＧＭＰが一例として使用されているが、ＩＧＭＰに限定されるべきではない。本発明の機能はＭＬＤの使用によっても得られる。
【０００８】
原則として、ＩＧＭＰはそのタスクを遂行するために２つの基本的なメッセージを使用する。メンバシップ報告メッセージ及びメンバシップクエリー（問い合せ）メッセージであり、以下の規則が適用される。異なるバージョンのＩＧＭＰも追加のメッセージを含む。
【０００９】
マルチキャストルータは、ホストがグループに所属しているか否かを確認するために一定間隔でメンバシップクエリーを送信する。ルータは、インタフェースごとに１つのクエリーを送出しなければならない。各ホストの１以上のメンバを含むグループごとに１つの応答をホストから受信することをルータは期待するので、クエリーのグループアドレスは０である。全てのグループに対してではなく、ある特定のグループにメンバシップクエリーを送信することもできる。ホストは、少なくとも１つのユーザを含むグループごとに１つのＩＧＭＰ報告を送信することでＩＧＭＰクエリーに応答する。また、ホストはメンバシップ報告を送信することによってグループに参加する。
【００１０】
報告メッセージ及びクエリーメッセージを適用することで受信される情報を使用して、マルチキャストグループ内の少なくとも１台のホストを有するインタフェースを伴うテーブルが構築される。ルータは、受信されたマルチキャストデータを、インタフェースを介して転送する。このインタフェースは少なくとも１つのメンバを有する。
【００１１】
ＩＰマルチキャストにより、受信者は送信者が誰であるか及びどこでトラフィックを受信するかを知る必要がなく、送信者は受信者が誰であるかを知る必要がなくなる。ネットワークが配信を最適化するため、送信者も受信者もネットワークトポロジについて考慮する必要はない。ＩＰマルチキャストを介する情報の配信は、例えば、マルチキャスト配信ツリーのようなホストの階層的な接続に基づいて実行される。スパンニングツリー、共有ツリー、送信元ツリー、コアベースツリーのようなマルチキャスト配信ツリーを構築するために、幾つかのアルゴリズムが提示されている。対応するアルゴリズムの説明は、「IP telephony: Packet based multimedia communications systems」（O. Hersent, D. Gurle, D. Petit, Addison Wesley, Harlow、2000）にある。マルチキャスト配信ツリーの構築後、ＩＰマルチキャストルーティングプロトコルにより情報の配信が行なわれる。対応するＩＰマルチキャストルーティングプロトコルの詳細な説明も上述の文献において見出される。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
ＩＰマルチキャストの利点は、異質の受信者をサポートしていることである。ＩＰマルチキャストにより、異なる媒体（メディア）を異なるマルチキャストグループに送信することが可能になり、受信者は自己の能力及び／又は好みに応じてどの媒体を受信するかを決定することが可能となる。同様に、送信者がビデオストリーム又は音声ストリームを階層（レイヤ）化する場合、各受信者は異なるトラフィック量及び異なる品質を選択することができる。これを実現するには、送信者が許容最低品質であるベースレイヤと複数の拡張レイヤとしてビデオを符号化しなければならない。拡張レイヤが１層加わるごとに品質は向上するが追加の帯域幅が必要となる。ビデオに関して、これらの追加のレイヤによって、フレームレートの増加、画像の空間分解能の向上、あるいは、その双方が実現されるであろう。各レイヤは異なるマルチキャストグループへと送信されるため、受信者は受信を申し込むレイヤの数を個別に決定することができる。
【００１３】
固定網と汎用パケット無線システム（ＧＰＲＳ）又はユニバーサル移動通信システム（ＵＭＴＳ）などの移動網との間のインターネットワーキングにおけるマルチキャスティングでは、さらなる問題が発生する。この問題は、例えば、エンドユーザの移動性及びエアインタフェースにおける移動網の伝送帯域幅の狭さに起因している。また、ＵＭＴＳなどの移動通信網における通信はユニキャスト通信である。ユニキャスト通信はポイントツーポイント通信とも呼ばれる。ポイントツーポイント通信とは、１人の送信者から１人の受信者へとメッセージを送信することを意味する。このようなネットワーク、特に、コアネットワークでは、マルチキャスト通信を実行することは想定されていない。グループ通信は、送信者がグループの各メンバに個別にポイントツーポイント通信によってパケットを送信することで実現される。ｎ人のメンバを有するグループの場合、マルチキャスト伝送が使用されるときには１個のパケットで良いのに対し、送信者と受信者との間で全体としてｎ個のパケットが必要である。
【００１４】
以下の記述では、ポイントツーポイント向きの通信システムにおいて発生する問題を説明するために、汎用パケット無線システム（ＧＰＲＳ）ネットワークのアーキテクチャの概要を示すことにする。
【００１５】
ＧＰＲＳは、回線交換網である移動通信用グローバルシステム（ＧＳＭ）をパケット交換へと拡張したものである。これによれば、ユーザは常時オンライン接続しつつも、実際のデータ転送に対してのみ料金を支払えば良いことを意味する。新規の必要条件を満たすために、幾つかの変更がＧＳＭ、とりわけ、新規の論理ノードに導入される。すなわち、サービング（在圏）ＧＰＲＳサポートノード（ＳＧＳＮ）及びゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）が導入される。ＧＧＳＮの主な機能は、例えば、インターネットサービスプロバイダ（ＩＳＰ）への接続を提供する外部のＩＰパケット網との相互作用を含む。外部のＩＰネットワークの観点から見ると、ＧＧＳＮは、ＧＰＲＳネットワークによるサービスを受ける全ての加入者のＩＰアドレスに対するルータとして機能する。また、ＧＧＳＮは、ルーティング情報を外部のネットワークと交換する。ＳＧＳＮは、地理的なＳＧＳＮサービスエリア内に物理的に位置している全てのＧＰＲＳ加入者に対してサービスを提供する。ＳＧＳＮは、移動局宛の受信ＩＰパケット又は移動局からの送信ＩＰパケットを転送する。新規の論理ノードに加えて、ノード間の新規のインタフェースが定義される。本発明では、特に、Ｇｎインタフェース、Ｇｉインタフェース、Ｇｐインタフェースが関係する。Ｇｐインタフェースは、異なるオペレータに所属するＧＧＳＮノード間で定義される。Ｇｎインタフェースは、ＳＳＧＮとＧＧＳとの間のＩＰベースのバックボーンを定義する。Ｇｉは、ＧＧＳＮとインターネットなどのさらに別のネットワークとの間のインタフェースである。ＧＰＲＳへの制限は、選択された技術の上でＩＰが実行されることでＧＧＳＮとＳＳＧＮとが接続されなければならないことである。これは、ＳＧＳＮ及びＧＧＳＮがＩＰアドレスを介して通信することを意味する。アーキテクチャの詳細な説明は、3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)にある。
【００１６】
同様のノード及びインタフェースは、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に記載されているように、次世代の無線ネットワーク、すなわち、ＵＭＴＳでも使用される。ＵＭＴＳにおけるこれらのノードの機能を区別するために、拡張名（３Ｇ−ＳＧＳＮ及び３Ｇ−ＧＧＳＮ）を使用することにする。以下の説明では、ＧＰＲＳノードとＵＭＴＳノードとの間で区別はしない。
【００１７】
以下の説明では、上述のようなthe 3GPP specifications, UMTS Standard 23.060で規定されるようなＵＭＴＳネットワークの概要を示す。
【００１８】
図１は、Ｐａｃｋｅｔとして示されるパケット交換ドメインとしてのコアネットワークを示している。コアネットワークは、Ｒａｄｉｏ ＮＷとして示される無線ネットワークに接続される。コアネットワークのパケット交換ドメインの上には、ＩＰマルチメディアサブシステム（ＩＭＳ）、すなわち、会話型マルチメディアサービスのためのＩＰ Ｍｕｌｔｉｍｅｄｉａ（ＩＰマルチメディア）がある。各サブシステムは対応するノードを含む。本発明において関連するのは、コアネットワークのノード、すなわち、関係するインタフェースＧｎ、Ｇｉを有するＳＧＳＮノード及びＧＧＳＮノードである。これらのインタフェースについては後で詳細に説明する。同様に関連するＧｐインタフェースは図１に示されていない。一例としてのＩＭＳは、パケット交換ドメインを使用して、会話型マルチメディアサービスへのベアラを提供する。例えば、対応するパケット交換ベアラの上部のインターネットにおいてストリーミングサーバを使用することによって、ＩＭＳなしでもストリーミングマルチメディアサービスを実現可能である。
【００１９】
ストリーミング／会話型マルチメディアサービスの導入により、多くの新規のポイントツーマルチポイントサービスが進化するであろう。これらのサービスは、ネットワークインフラストラクチャに対する要求が高く、かなりの帯域幅を使用する。これらのサービスの例としては、ビデオ会議、電子黒板、リアルタイムマルチユーザゲーム、マルチメディアメッセージング、仮想世界などがある。
【００２０】
図１によると、インターネットのような外部のＩＰネットワークがＭｕｌｔｉｍｅｄｉａ／ＩＰ Ｎｅｔｗｏｒｋ（マルチメディア／ＩＰネットワーク）として示され、移動局はＴＥ、コアネットワークはＰａｃｋｅｔとして示されている。現在、ＵＭＴＳにおけるＩＰマルチキャストメッセージは、外部のＩＰネットワークに設置されるルータから移動局までユニキャスト接続を介して透過的に送信される。既に説明したように、マルチキャストはＩＰレイヤ上で実行される。移動局ＴＥの観点から見ると、インターネットのルータはＩＰ接続が終了する最初のノードであり、マルチキャストに適用可能な最初のノードである。これは、外部ネットワークに対する通信を可能にするＧＧＳＮのＩＰレイヤがマルチキャストを実行可能とは、現在のところ想定されていないことを意味する。ルータは、マルチキャストメッセージとユニキャストメッセージとを区別せずに、移動網のコア部分内でマルチキャストメッセージを送信する。マルチキャストフローの分離はインターネットのルータで既に行なわれており、同じデータパケットが受信者の人数に応じて複数回無線ネットワークを介して送信される。
【００２１】
これは、既存のＵＭＴＳ技術が、図１のＧｎインタフェースとして示されるネットワークの部分での効率的なマルチキャスティングの利用を想定していないことを意味する。複数のクライアントに同時に提供されるサービスは、無線ネットワークの終端で複製され、複数のユニキャスト接続がクライアントに対して使用される。特に、リソースの需要が高いストリーミングマルチメディアサービス又は会話型マルチメディアサービスの進化においては、ネットワークのリソースが非効率的に使用されることを意味する。
【００２２】
さらに、既存のノードは、マルチキャスティングを実行するように構成されていない。
【００２３】
一般に、ポイントツーポイント向きののネットワークでマルチキャストを導入・実行すると本質的な問題が発生する。このようなネットワークでは、２台のノード間の通信を実行するためにユニキャストチャネルが確立される。これは、ＵＭＴＳのような無線ネットワークでのみ問題が発生するのではないことを意味する。
【００２４】
マルチキャストが可能なプロトコルのさらなる例としては、ＳＩＰ（セッション開始プロトコル）又はＲＴＳＰ（リアルタイムストリーミングプロトコル）がある。ＳＩＰプロトコルは、ＩＥＴＦのマルチパーティ・マルチメディア・セッション・コントロール（ＭＭＵＳＩＣ）ＷＧに記載されており、ＲＴＳＰは、RFC 2326 「Real Time Streaming Protocol (RTSP)」（H. Schulzrinne, A. Rao, R. Lanphier、１９９８年４月）によりカバーされている。これらのプロトコルは、ポイントツーポイント向きのプロトコルに所属し、以下に説明する発明もこれらのプロトコルに適用される。
【００２５】
本発明の目的は、ポイントツーポイント向きのパケット交換通信ネットワークにおけるマルチキャストの効率的な導入・実行に対する解決法を提供することである。
【課題を解決するための手段】
【００２６】
本発明は、請求項１、２４、２６、及び２７に開示される方法、ルータ、在圏ノード、及びシステムにおいて具象化される。有利な実施例は各従属請求項に記載される。
【００２７】
基本的概念は、ＧＧＳＮなどの少なくとも１台のルータと、少なくとも１つのユーザ装置を処理する少なくとも１台の在圏ノードとを有するポイントツーポイント向きのパケット交換通信ネットワークの各部に接続するマルチキャストグループに対して、事前に設定・確立されたデフォルトのマルチキャスト伝送を使用することである。ユーザ装置は例えば移動局などであり、在圏ノードは例えばＳＧＳＮなどであり、ポイントツーポイント向きのパケット交換通信ネットワークは例えばＵＭＴＳなどである。前記ネットワークは、それ自体で複数のマルチキャストグループを提供することができる。当該ネットワークは、登録可能な複数のマルチキャストグループを有するさらなるネットワークに接続することができる。さらなるネットワークとは例えばインターネットなどである。事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、前記ルータと前記在圏ノードとの間にＧＴＰなどのトンネリング用のトランスポートレイヤプロトコルにより事前に確立され、当該トンネルがマルチキャストグループに対して割り当てられる。複数のマルチキャストデータストリームが前記トンネルについての事前設定に合致する場合、前記ルータは、前記ストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化する可能性がある。マルチキャストデータの伝送は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して、前記ルータから前記在圏ノードに対して実行される。対応するマルチキャストグループに登録されたユーザに対してデータを転送するために、必要に応じてマルチキャストデータの非多重化（分離処理）が前記在圏ノードにおいて行なわれる。
【００２８】
前記在圏ノードは、前記マルチキャストグループに登録され、かつ前記在圏ノードによりシャンデルされるユーザが２以上いる場合、前記複数のマルチキャストデータストリームの複製を行なう。
【００２９】
さらなる記述において、ユーザの説明を行なうのに一例として移動局が使用されるが、ノードをユーザと見なすこともできる。一般的に、ユーザはマルチキャストグループのメンバを意味する。
【００３０】
本発明の好適な実施例では、前記トランスポートレベルのマルチキャストグループトンネルの事前設定は、複数の異なるサービスクラスに従って行なわれる。例えば、ＵＭＴＳでは、サービス品質ＱｏＳにおいて異なる必要条件を有するストリーミングサービスクラス又は会話型サービスクラスのような複数の異なるサービスクラスが存在する。これらの必要条件によると、所要のＱｏＳ必要条件をサポートする事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。この方法の有利な実施例では、負荷分散及び冗長性のために２以上の事前に設定されたトランスポートレベルのマルチキャストグループトンネルが確立される。これは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと前記サービスクラスの組み合わせを構築できることを意味する。例えば、ストリーミングサービスクラスに対して、２つの事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。
【００３１】
別の実施例では、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、別のパラメータ、すなわち、都市又は国などの地理的領域に従って確立することができる。ＳＧＳＮなどの１台以上の在圏ノード又はＧＧＳＮなどの１台以上のルータによりカバーされるエリアも地理的領域を定義することができる。さらなるパラメータの組み合わせも定義することができる。例えば、特定の地理的領域に対して、異なるサービスクラスを有する複数の事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立することができる。
【００３２】
前記在圏ノードは、前記ルータに対してトランスポートレベルのマルチキャストグループへの接続又は前記グループからの解放に対する関心を通知するのが好ましい。前記トランスポートレベルのマルチキャストグループは、ユーザが登録することのできるマルチキャストグループに関連している。トランスポートレベルのマルチキャストグループの各メンバへのマルチキャスト伝送は、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して行なわれる。
【００３３】
また、前記ルータが在圏ノードに対して前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルの確立を管理することも可能である。これは管理インタフェースにより行なわれ、たとえば、在圏ノードがネットワークに接続される開始手順中に行なうことができる。前記ルータは、前記在圏ノードの各パラメータを受信し、これらのパラメータに従ってトランスポートレベルのマルチキャストグループトンネルが確立される。
【００３４】
前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、事前に設定されたマルチキャスト配信ツリーを使用する。この配信ツリーは、前記ルータと少なくとも１台の在圏ノードとの間に作成される。前記ツリーはマルチキャストルーティングプロトコルにより確立される。
【００３５】
マルチキャストグループは、対応するサービスクラスのマルチキャストトンネルの上でトラフィックを送信するのに、サービスクラスにより提供されるＱｏＳ特性を必要とする。この関係で、マルチキャストグループはサービスクラスに所属していると言うことができる。本発明の好適な実施例では、同じサービスクラスに所属する複数のマルチキャストグループの多重化が、前記サービスクラスをサポートするために事前に設定された同一のトランスポートレベルのマルチキャストグループトンネル上で行なわれる。
【００３６】
前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを管理するために、データ構造を使用することが想定される。データ構造のタスクは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記マルチキャストグループの登録ユーザと、前記マルチキャストグループのマルチキャストアドレスとの関連付けを管理することである。前記データ構造は、ネットワークノードにおいて集中管理することも、あるいは、ネットワーク内で分散管理することもできる。
【００３７】
特に、これは、前記ルータ及び／又は前記在圏ノードにおいて、あるいは、１つ又は複数の他のネットワークエンティティによりデータ構造を管理することができることを意味する。
【００３８】
本発明の好適な実施例において、特定のサービスクラスを要求するユーザが、事前に設定されたどのトランスポートレベルのマルチキャストグループトンネルに割り当てられるべきかを決定するために、前記データ構造は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと前記サービスクラスとの間の関係を含む。
【００３９】
本発明の好適な実施例では、前記在圏ノードはユーザに対して中継するマルチキャストデータパケットの個数と破棄するマルチキャストデータパケットの個数とについての統計値を収集し、その結果によりトランスポートレベルのマルチキャストグループへの登録を解除する決定が下される。マルチキャストから得られるよりも、マルチキャストトラフィックを破棄するのにより高い処理能力が必要とされるので、前記在圏ノードはこの情報に基づいてＴＬＭＧへの登録の解除を決定しても良い。
【００４０】
本発明の好適な実施例では、前記在圏ノードは事前に設定されたトランスポートレベルのマルチキャストグループトンネルの一部になることを望むか否かを決定する。どの在圏ノードに前記マルチキャストデータが送信されるかを見出すためには、事前に設定されたトランスポートレベルのマルチキャストグループトンネルに登録された在圏ノードの台数を管理するのが好ましい。しかし、前記ルータは、何台の及びどの在圏ノードが対応するトランスポートレベルのマルチキャストグループに接続されるかの情報を入手することなく、前記トランスポートレベルのマルチキャストグループトンネルにデータを送信することもできる。
【００４１】
好適な実施例では、前記複数のマルチキャストデータストリームは、事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化される。前記受信中の多重化された複数のデータストリームを分離するためには、前記在圏ノードはマルチキャストグループの一部であるユーザを判定すべく、各ストリームを区別するパラメータを管理する。これは、例えば、さらなるネットワークに存在するマルチキャストグループのマルチキャストアドレスであっても良く、アドレスはデータパケットに含まれる在圏ノードへと送信される。
【００４２】
本発明による方法を実行するために、登録及び登録解除手順が定義されるべきである。好適な実施例では、ユーザのマルチキャストグループへの登録又はマルチキャストグループへの登録解除を行なうために、ユーザは前記ルータに対して通知し、前記ルータは前記在圏ノードに通知し、前記データ構造中の対応するエントリの更新が行なわれる。
【００４３】
移動網は、特に、ユーザの移動により特徴づけられる。従って、手順が適用されると、データの連続的な受信が保証されることになる。このため、ユーザが前記在圏ノードを変更する場合、ユーザの新規の在圏ノードへの登録、以前の在圏ノードからの削除、及び前記ルータ中の前記対応するエントリの更新が実行される。
【００４４】
この手順としては、メッセージ交換を信号で通知するための制御シグナリングプロトコルが使用される。また、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立するために使用される前記トンネリング用のトランスポートレイヤプロトコルは前記プロトコルの一例である。
【００４５】
前記制御シグナリングプロトコルの一例は、ＵＭＴＳで使用されるようなＧＰＲＳトンネリングプロトコル（ＧＴＰ）である。
【００４６】
本発明の有利な実施例では、マルチキャストグループのマルチキャストアドレスの代わりに、ＧＴＰで定義されるＧＴＰトンネリングＩＤ（ＴＩＤ）を前記在圏ノード中の前記複数のマルチキャストストリームを分離するための識別用パラメータとして使用することができる。
【００４７】
本発明の好適な実施例では、前記マルチキャストは、マルチキャスト対応ルータに含まれるマルチキャスト・ルーティング・テーブルに従ってユーザへのルートを定義するために、ＩＰマルチキャストアドレスを有するＩＰパケットを使用するＩＰマルチキャストである。
【００４８】
マルチキャストグループへの登録及びマルチキャストグループからの解放のために、既存のＩＧＭＰ又はＭＬＤプロトコルを使用することも好ましい。これらは周知のプロトコルであり、本発明の好適な実施例では、ネットワークリソースを節約するために変更される。これは、現在、前記ルータがＩＧＭＰ要求メッセージによりマルチキャストグループへの登録が行なえる態勢にあるかユーザに尋ねることを意味する。このＩＧＭＰメンバシップクエリーは定期的に送信される。伝送リソースを節約するためには、ユーザが希望に応じてマルチキャストグループに登録する方がより効率的である。
【００４９】
通信ネットワーク内でマルチキャスト伝送を行なうようにルータを適合させることが提案されている。前記ルータは、前記在圏ードに対して事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立するためのロジック（論理手段）を有する。さらに、前記ルータは、前記複数のマルチキャストデータストリームが前記トンネルの事前設定と一致する場合に、複数のマルチキャストデータストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化するためのロジックを含む。また、前記ルータは、マルチキャストデータを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して前記在圏ノードへと転送するためのロジックを含む。これは、例えば、さらなるネットワークから前記マルチキャストデータを受信することと、受信者のアドレスを分析することと、前記アドレスの前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへの変換と、前記マルチキャストデータをこのトンネルに送信することとを含む。
【００５０】
前記ルータが前記さらなるネットワークへと前記マルチキャスト登録を伝播するためのロジックを含むことも提案されている。ユーザがマルチキャストグループに登録している第１のユーザである場合に伝播処理が必要である。これは、前記さらなるネットワーク中の隣接するルータに対し、対応するグループのマルチキャストデータを送信されるべき特定のマルチキャストグループに、少なくとも１つのメンバがいることを通知する必要があることを意味する。
【００５１】
前記ルータが、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記マルチキャストグループの登録ユーザと、前記マルチキャストアドレスとの関連付けの管理用のデータ構造を制御することが提案される。
【００５２】
さらに、在圏ノードは、通信ネットワーク内でマルチキャストを行なうように構成される。在圏ノードは、前記事前に設定されたトランスポートマルチキャストグループトンネル上で前記ルータからマルチキャストデータを受信するためのロジックを有する。前記事前に設定されたトランスポートレベルのマルチキャストグループと対応するマルチキャストグループに登録されたユーザとを管理するためのロジックは、事前に設定されたトランスポートレベルのマルチキャストグループトンネルからどのユーザにデータが送信されるかを知るために必要とされる。さらに、在圏ノードは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で複数のマルチキャストデータストリームが多重化されている場合にこれらを分離するためのロジックを必要とする。２以上のユーザがいる場合、マルチキャストデータは前記ユーザ間で前記受信されたマルチキャストデータを複製するためのロジックにより複製される。
【００５３】
さらに、ルータと複数のユーザを処理する在圏ノードとを有する通信ネットワーク内でマルチキャストを行なうように構成されるシステムを有することが提案される。上述の特徴により、各ノードの機能が拡張され、システムは上述の方法に従って動作する。
【００５４】
ＵＭＴＳなどのモバイル環境において、在圏ノードの一例であるＳＧＳＮとルータの一例であるＧＧＳＮとの間のＩＰネットワークの伝送を効率的にするために、ＩＰマルチキャストを使用することによって、これらの技術思想は実現できるであろう。
【００５５】
本発明の利点は、無線ネットワークにおいて乏しくかつ高価なネットワークリソースを効率的に利用できることである。
【００５６】
さらに、Ｇｎインタフェース及びＧｐインタフェースの場合、各リンク上でパケットのコピーを１つだけ伝送することによって、ＧＰＲＳ又はＵＭＴＳの伝送を効率良くすることができる。これにより、同じマルチキャストグループに対して複数のユーザが、同じ又は異なるＳＧＳＮに位置する場合は、全体での伝送リソースを減少させることができ、輻輳防止のアルゴリズムの必要性や負荷分散アルゴリズムの必要性が限定的なものとなろう。
【００５７】
例えば、事前に設定されたトランスポートレベルのマルチキャストグループトンネルなど、ネットワークの各部について事前に設定されたマルチキャスト伝送を使用することにより、マルチキャストグループの設定時間を減少させることができる。これは、ユーザが特定のマルチキャストグループに登録又はグループから脱退する場合、あるいは、ユーザが在圏ＳＧＳＮを変更する場合に、マルチキャスト配信ツリーを確立する必要がないからである。さらに、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを使用することによって、拡張サービスの提供と、異なるマルチキャストグループの多重化とを、同一のトランスポートレベルのマルチキャストグループトンネル上で達成できる。
【００５８】
以下の記述では、事前に設定されたトランスポートレベルのマルチキャストグループトンネルに割り当てられるトランスポートレベルのマルチキャストグループをＴＬＭＧと呼ぶ。
【発明を実施するための最良の形態】
【００５９】
次に、本発明を詳細に説明する。図２及び図３を参照して説明を行なう。
【００６０】
ツリー構造を伴う図２の上部は、外部のＩＰネットワーク内でのマルチキャストを示している。ＩＰネットワークは、Ｇｉインタフェースを介してＧＧＳＮに接続される。ＧＧＳＮからＳＧＳＮへの伝送は、Ｇｎインタフェースを介して行なわれる。Ｇｎインタフェースでの伝送は複数のノードを介することができる。これは、図２の中央部に相互に接続されたノードにより示されている。下部は、異なる無線ネットワークを示しており、これらのネットワークは、それぞれ対応するＳＧＳＮからサービスが提供される。図２で最も重要な部分は、ネットワークの中央部、すなわち、Ｇｎインタフェースである。このＧｎインタフェースには、ＧＧＳＮから２台のＳＧＳＮへとトラフィックを転送するためにマルチキャスティングが適用される。ＳＧＳＮは、対応する無線アクセスネットワークへとトラフィックを転送する。
【００６１】
図３にはプロトコルの関連図が示されている。図３は、３ＧＰＰで標準化されているネットワークのアーキテクチャを示している。なお、このアーキテクチャは本発明を限定するものではない。図３は、Ｕｕインタフェースを介してアクセスネットワークＵＴＲＡＮと通信を行なう移動局ＭＳを示している。Ｉｕ−Ｐｓインタフェースは、ＵＴＲＡＮと３Ｇ−ＳＧＳＮとを接続するものである。３Ｇ−ＳＧＳＮは、Ｇｎインタフェースを介して３Ｇ−ＧＧＳＮと通信を行なう。図３は、ＵＭＴＳで使用される様々なノードの様々なプロトコルスタックの概要を提供する。以下の説明では、例えば、ＩＰ、ＰＰＰ、及びＵＤＰ／ＩＰとして示される、パケット交換ドメインにおける２種類のＩＰレイヤと、ＧＴＰ−Ｕレイヤとに絞って説明を行なう。図３では、他のプロトコルについて補足を目的として言及する。
【００６２】
ＳＧＳＮ又はＧＧＳＮのように上述したパケット交換向きのノードの機能及び通信方法については、上述の必要条件及び制限があるため、開発されたプロトコルスタックに影響を及ぼしている。ルータとして及び外部のネットワークへのインタフェースとして機能するために、ＧＧＳＮには、アプリケーションレイヤの下側にＩＰレイヤが導入されている。ＧＧＳＮとＳＧＳＮとの間ではＩＰネットワークを備えるには制限があるため、トランスポート手段としてＧＴＰ−Ｕレイヤの下位にＩＰ論理コネクションが導入されている。
【００６３】
従って、図３には２種類のＩＰレイヤが存在し、以下の説明では、アプリケーションＩＰレイヤとトランスポートＩＰレイヤとして示している。プロトコルスタックのアプリケーションＩＰレイヤは、アプリケーションプロトコルＡｐｐｌｉｃａｔ．の真下に位置し、移動局と３Ｇ−ＧＧＳＮとを接続している。このＩＰレイヤは、パケット交換網にとって透過的である。この透過性は、図３のＭＳから３Ｇ−ＧＧＳＮに至る直線により示される。第２のＩＰレイヤは、ＳＧＳＮとＧＧＳＮとＵＴＲＡＮとの間の伝送に使用されるトランスポートＩＰレイヤである。ペイロードトラフィックは、アプリケーション固有のトンネリングプロトコル、すなわち、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）によってカプセル化され、Ｇｎ及びＩｕ−ＰＳを介して転送される。ＧＴＰは、トンネリング用のトランスポートレイヤプロトコルの一例である。ＧＰＲＳにおいて、ＧＴＰプロトコルは、ＳＧＳＮとＧＧＳＮとの間でのみ使用される。ＧＴＰパケットは、トランスポートプロトコルとしてＵＤＰを使用する。なお、トンネルを形成するトンネリングプロトコルには様々なものがある。ＧＴＰはその一例に過ぎない。
【００６４】
ポイントツーポイント向きのパケット交換ネットワークへのマルチキャストの導入が図４に示される。図４は、プロトコルスタックの最上位にアプリケーションレイヤＡｐｐｌ．を有し、ネットワークレイヤ上にインターネットプロトコル（ＩＰ）又はポイントツーポイントプロトコル（ＰＰＰ）を有する移動局ＭＳを示している。下位の層はＬ１レイヤ及びＬ２レイヤとして示されているが、これは、それぞれのノードにおいて基礎となる物理的なネットワークに依存して異なる可能性があるからである。移動局からの論理ＩＰコネクション又はＰＰＰコネクションは、３Ｇ−ＧＧＳＮにおいて終端する。ＵＴＲＡＮ、３Ｇ−ＳＧＳＮ、及び３Ｇ−ＧＧＳＮの各ノード間では、トンネルを形成するのにＧＴＰ−Ｕプロトコルが使用される。ＧＴＰ−Ｕの下位には、ペイロード情報の転送用のプロトコルとしてＵＤＰを有するＩＰレイヤが位置する。
【００６５】
ここで示される技術思想は、例えば、ＧＴＰのようなトンネリングプロトコルより下側の層であるＩＰレイヤ上にマルチキャスト機能を導入することである。図４において、３Ｇ−ＳＧＳＮと３Ｇ−ＧＧＳＮとの間のマルチキャストとして示される陰影部によりこの思想を示している。Ｇｉインタフェース上のマルチキャスト陰影部からＧｎインタフェース上のマルチキャスト陰影部へと向かう矢印は、アプリケーションＩＰレイヤ上で実行されるマルチキャストをトランスポートＩＰレイヤへと導入することを示している。これは、Ｇｉインタフェースを介して３Ｇ−ＧＧＳＮに到着するマルチキャストデータの宛先が、ＧＧＳＮとＳＧＳＮとの間のマルチキャストを実行する下層のＩＰレイヤに変更されることを意味する。ＵＴＲＡＮにおけるＳＧＳＮとＲＮＣとの間のコネクションはユニキャストのままである。また、ＩＰレイヤ上の論理ポイントツーポイントのコネクションも残されている。
【００６６】
以下の説明では、本発明で必要とされるＧＧＳＮの拡張機能が説明される。
【００６７】
新規のタスクを実行するために、ＧＧＳＮは、加入者から送信されるＩＧＭＰメッセージ又はＭＬＤメッセージを処理可能なローカルマルチキャストルータとして機能しなければならない。ＧＧＳＮは、ＩＧＭＰメッセージ又はＭＬＤメッセージを終端させ、関連する情報をＩＧＭＰ又はＭＬＤを介して隣接するルータへと転送する。ＧＧＳＮはマルチキャストルーティングプロトコルも扱う。加入者はＧＧＳＮの特定のマルチキャストグループに登録し、ＧＧＳＮはパケット交換網のアクティブなマルチキャストグループを常時監視する。これまでの説明では、ＧＧＳＮは標準のローカルマルチキャストルータに非常に類似した動作を行なう。一般的に、公衆陸上移動通信網（ＰＬＭＮ）の外部ローカルマルチキャストルータが、ＧＧＳＮの代わりに使用されてもよい。
【００６８】
また、ＧＧＳＮは、コアネットワークの範囲に事前に設定されたマルチキャストグループを事前に確立する。実際には、ＧＧＳＮとトランスポートレイヤ上のＳＧＳＮのような全ての対象ノードとの間に、ソースベースのマルチキャストツリーが生成される。データをＳＧＳＮへと配信するには、ＩＰマルチキャストを使用するのが好ましい。データが配信されると、ＳＧＳＮはパケットを複製してこれを関係する移動局へと転送する。本発明がＳＧＳＮとこれに接続するＲＮＣとの間のインタフェース上で使用されるような場合には、ＲＮＣがパケットを複製する。上述のマルチキャストグループは、いわゆる事前設定されたトランスポートレベルのマルチキャストグループ（ＴＬＭＧ）と呼ばれる。
【００６９】
本発明の基本的概念は図５を参照して開示される。
【００７０】
図５は、異なる構成のコネクションを介して４台のＳＧＳＮと通信を行なうＧＧＳＮを示している。ＧＧＳＮとＳＧＳＮとの間では、事前に設定されたＴＬＭＧが事前に確立される。各点線は、異なる事前設定のＴＬＭＧを示している。ＴＬＭＧはコアネットワークの範囲を有する。すなわち、ＳＧＳＮからＧＧＳＮまでの範囲である。ＴＬＭＧは、Ｇｉインタフェース上で受信されたマルチキャストトラフィックを、Ｇｎインタフェースを介してＳＧＳＮへと転送する際に使用される。ＴＬＭＧは、例えば、異なるサービス品質（ＱｏＳ）パラメータなどの異なるサービスクラスに基づいて、任意に多重化された複数のマルチキャストストリームを転送することができる。ＳＧＳＮにおいて、ストリームは必要に応じて分離されて複製される。例えば、ＳＧＳＮとＭＳとの間ではユニキャスト伝送が使用される。ＴＬＭＧは事前に確立されているので、ＴＬＭＧの確立によりＧＧＳＮと対象のＳＧＳＮとの間におけるマルチキャストグループの登録がさらに遅延することはない。
【００７１】
事前に設定されたＴＬＭＧの概念は、運用・保守又はネットワークエンティティ間の設定メッセージにも使用することができる。
【００７２】
以下の説明では、本発明の好適な実施例を示す。この実施例では、Ｇｎインタフェース上でのマルチキャスティングを説明する。これは、ＧＧＳＮとＳＧＳＮとの間でのマルチキャスティングを意味する。トランスポートレベルのマルチキャストを、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）又はセッション開始プロトコル（ＳＩＰ）などをベースとした他のポイントツーポイントネットワークに適用する際にも、同様のメカニズムを使用することができる。さらに、ＧＧＳＮと、別のＰＬＭＮに配置されたＳＧＳＮとの間のＧｐインタフェースにも同様のメカニズムを適用可能である。
【００７３】
ＳＧＳＮは、ＩＧＭＰを使用して特定のＴＬＭＧに関心があることを、対応するＧＧＳＮに通知する。別の方法では、ＧＧＳＮが、ＴＬＭＧに接続されるＳＧＳＮを管理する。ＧＧＳＮ及びＳＧＳＮの少なくとも一方において実施可能なこの管理処理は、管理インタフェースにより制御される。管理インタフェースは、例えば、ネットワーク管理で知られている運用・保守（Ｏ＆Ｍ）インタフェースであっても良い。オペレータは、例えば、ＳＧＳＮの構成を設定することができ、運用開始後、事前に設定されたＴＬＭＧをＧＧＳＮが事前に確立する。このときの事前設定はＳＧＳＮの必要条件に対応している。ＳＧＳＮの事前設定に対する変更は、管理インタフェースによっても実施することができる。事前に設定されたＴＬＭＧは、ルーティングプロトコルにより確立することができる。マルチキャスト・ルーティング・プロトコルは、ルートとしてのＧＧＳＮ及びリーフとしてのＳＧＳＮを有するマルチキャスト配信ツリーを構築するのに使用される。
【００７４】
ＵＭＴＳネットワークでは、会話型サービス又はストリーミングサービスなど、様々なサービスクラスが使用されるため、ＴＬＭＧはサービスクラスごとに作成される。マルチキャスト・ルーティング・プロトコルは、対応するマルチキャスト配信ツリーを構築する際に必要とされるサービス品質（ＱｏＳ）を考慮する。負荷スケジューリング手段を提供するため、サービスクラスごとに複数のＴＬＭＧを作成することもできる。
【００７５】
ＴＬＭＧは、管理インタフェースを介して差別化サービスコードポイント又はサービスタイプ（ＴｏＳ）の設定を使用するように事前に設定することができる。これは、ＵＭＴＳベアラクラスと関連付けられ、対応するＩＧＭＰメッセージのルーティング及びマルチキャスト配信ツリーの構築に使用される。
【００７６】
結果として、図６に示したように、ＧＧＳＮとこれに接続された全てのＳＧＳＮとの間に、複数のサービスクラスベースマルチキャスト配信ツリーが作成される。
【００７７】
図６は、ＱｏＳルーティングに基づく３つの異なるマルチキャスト配信ツリーを示している。図６では、ＧＧＳＮとＳＧＳＮとの間に異なる点線を描くことで示されている。ツリー構造が異なっているのは、ツリーの構築の際に、ＱｏＳメトリクス又はサービスクラスが考慮されるためである。各リンクでは、複数のマルチキャストグループが多重化されていても良い。これは、複数のマルチキャストグループがＴＬＭＧにより達成される同じＱｏＳ必要条件を有する限り、同じＴＬＭＧで転送されることを意味する。図６では、マルチキャストデータストリームＭＣ１−ｄａｔａ及びＭＣ２−ｄａｔａにより示される。これらのデータストリームは、同じ事前設定のＴＬＭＧ上で多重化される。これは、同じＴＬＭＧアドレス、すなわち、ＴＬＭＧ１アドレスにより示される。
【００７８】
図７は、後述のシグナリングシナリオで使用されるデータ構造を示している。一般的に、データは任意の方法で集中化又は分散化することができ、異なるネットワークエンティティ間の情報転送はそれに合わせて変更される。
【００７９】
図７は、ノードＳＧＳＮ及びノードＧＧＳＮを実際のエントリと共に示している。ＧＧＳＮは、現在６つのＴＬＭＧである、ｔｌｍｇ１からｔｌｍｇ６を有する。ＴＬＭＧは、例えば、サービスクラス欄に列挙されたストリーミング又は会話型などのサービスクラスに割り当てられる。異なるｔｌｍｇによってもサービスクラスをサポートすることができるので、ＴＬＭＧとサービスクラスとの組み合わせが異なってくる場合もある。以下の説明では、これをＴＬＭＧ／サービスクラスの組み合わせと呼ぶ。ＭＣ−ａｄｄｒｅｓｓ欄は、さらに別のネットワークにおけるマルチキャストグループのマルチキャストアドレスｍｃ１からｍｃ１０を含んでいる。このグループはある特定のｔｌｍｇと関連付けられている。例えば、マルチキャストアドレスｍｃ１及びｍｃ２がｔｌｍｇ１に割り当てられる。これは、マルチキャストアドレスｍｃ１及びｍｃ２を有するマルチキャストデータストリームがｔｌｍｇ１上で多重化されることを意味する。また、ユーザ数は＃ＭＳｅｓ欄において管理され、マルチキャストグループごとのユーザ数又はＴＬＭＧごとの適正数が監視される。以下の説明において、この関係はマルチキャストグループ／ＴＬＭＧとして略される。ＳＧＳＮの変更又はＰＤＰコンテキストの削除する際に、あるマルチキャストグループ／ＴＬＭＧにユーザが所属するか否かを判断するために、ＧＧＳＮはＴＬＭＧごとのユーザの情報を格納しても良い。別の方法では、例えば、１以上のマルチキャストグループに登録したユーザについてのＰＤＰコンテキストに対するＴＬＭＧマルチキャストアドレスをＧＧＳＮ識別情報に格納する。ユーザは、複数のアクティブなＰＤＰコンテキストを有し、このＰＤＰコンテキストの各々を、１以上のマルチキャストグループに登録してもよい。これは、ユーザが登録されたマルチキャストグループのために、追加の識別子を付すことにより、ＰＤＰコンテキストデータを拡張できることを意味する。ＰＤＰコンテキスト活動（アクティブ）化は、外部のＩＰネットワークにログオンするようなものである。この目的で移動加入者ＩＤがＩＰアドレスと関連付けられる。以下の説明において、ＰＤＰコンテキストの活動化中は、ＴＩＤで識別されるＩＤを有するトンネルが、ＰＤＰコンテキストのために、ＳＧＳＮとＧＧＳＮとの間に作成される。ＧＴＰがＰＤＰコンテキスト活動化中に使用される場合、ＧＴＰトンネルが確立される。この手順の間、サービス品質（ＱｏＳ）のネゴシエーションがＭＳとＳＧＳＮ／ＧＧＳＮとの間で実行される。
【００８０】
ＳＧＳＮは、同様のエントリをＧＧＳＮ、ＴＬＭＧ、Ｓｅｒｖｉｃｅ Ｃｌａｓｓ、ＭＣ−Ａｄｄｒｅｓｓ及び＃ＭＳｅｓとして管理する。マルチキャストデータストリームを区別し、ストリームの分離処理を実行するには、ＳＧＳＮにおけるマルチキャストアドレス及びそのＴＬＭＧとの関係を管理する必要がある。ＳＧＳＮの＃ＭＳｅｓ欄には、マルチキャストデータを特定の移動局に送信するために、ｔｌｍｇに所属するユーザの一覧が含まれている。
【００８１】
以下の説明において、サービスクラスの必要条件に従って事前に設定されるＴＬＭＧを、サービスクラスベースＴＬＭＧと呼ぶことにする。サービスクラスベースＴＬＭＧは、ＧＧＳＮ又は対応するＳＧＳＮにおいて管理されてもよい。ＴＬＭＧの設定がＧＧＳＮにおいて行なわれる場合、ＴＬＭＧ／サービスクラスの組み合わせが管理される。全てのＳＧＳＮがＴＬＭＧの一部である必要はない。これは、例えば、ＳＧＳＮがマルチキャストグループに登録したユーザを持たないこともあるからである。この場合、ＴＬＭＧからＳＧＳＮを削除すると決定してもよい。このため、登録されたＳＧＳＮはＧＧＳＮのＴＬＭＧの一部として管理されなければならない。必要に応じて、ＧＧＳＮは、ＴＬＭＧによってサービスを提供される少なくとも１つのマルチキャストグループメンバを抱えているＳＧＳＮの数をカウントするためのカウンタをＴＬＭＧごとに含んでもよい。ＴＬＭＧを介するマルチキャスティングが効率的か否かを、マルチキャストデータを受信して決定する際に、このＳＧＳＮの数を考慮に入れてもよい。これは、グループメンバを有するＳＧＳＮの数と、グループメンバを持たず、かつマルチキャストトラフィックを破棄するための追加処理を行なう必要があるＳＧＳＮの数との間の関係によって決まる。ＴＬＭＧに接続されるもののマルチキャストグループメンバを持たないときには、ＳＧＳＮはマルチキャストトラフィックを受信する。ＳＧＳＮはマルチキャストデータを転送することが可能なリーフを持たないため、このデータを破棄すべきである。
【００８２】
サービスクラスベースＴＬＭＧが各ＳＧＳＮにおいて管理される場合、ＳＧＳＮがその一部を形成すべきＴＬＭＧを、ＴＬＭＧ／サービスクラスの組み合わせに反映される。ＴＬＭＧ／サービスクラスの組み合わせがＧＧＳＮにおいて設定構築される場合は、ＳＧＳＮにおいてサービスクラスを省略することができる。
【００８３】
全てのＴＬＭＧサービスクラスの組み合わせについて、全てのＳＧＳＮが登録しているとは限らない場合、ＧＧＳＮはＴＬＭＧ／サービスクラスの組み合わせごとに登録されているＳＧＳＮの情報を監視しなければならない。ＳＧＳＮはＴＬＭＧの一部ではないため、この情報は、どのＳＧＳＮが、対応するＴＬＭＧによってマルチキャストトラフィックを受信するか及びどのＳＧＳＮが追加のユニキャスト伝送コネクションを必要とするかを判定するために必要となる。これは、全てのＳＧＳＮについての登録処理が完了していない状態で、マルチキャストストリームが到着したときに持て起用可能である。
【００８４】
以下の説明において、本発明の好適な実施例を示す。この実施例では、サービスクラスベースＴＬＭＧの確立処理と解放処理を説明する。図８及び図９に基づいて説明を行なう。図８及び図９は、ＧＧＳＮと２台のＳＧＳＮ、すなわち、ＳＧＳＮ１及びＳＧＳＮ２との間で送信されるメッセージを時系列的に示している。矢印は送信されるメッセージを示している。矢印の上方にメッセージの名称が示され、矢印の下方にメッセージにより搬送されるパラメータが列挙される。図８及び図９では、関連するパラメータのみが示される。右側の枠はメッセージ受信後にノードで実行されるアクションを示している。各記号の適切な意味は、以降の図面にも適用される。
【００８５】
図８のシーケンスは、設定がＧＧＳＮで行なわれる場合のサービスクラスベースＴＬＭＧ確立処理を示している。ＧＧＳＮは、ＴＬＭＧマルチキャストアドレスＴＬＭＧ−ＭＣＡｄｄｒを有するＴＬＭＧ登録要求をＳＧＳＮ１及びＳＧＳＮ２に送信する。このアドレスはＴＬＭＧの割当てマルチキャストアドレスである。ＱｏＳパラメータもこのメッセージに含まれる。既に説明したように、制御情報の交換にＧＴＰプロトコルを使用することができる。このためには、新規のメッセージによって、プロトコルを拡張する必要がある。これは、新規ＧＴＰというプリフィックスにより記述される。新規のメッセージをＧＴＰに導入するか、あるいは、新規の追加情報でもって既存のメッセージを改訂すればよい。ＩＧＭＰプロトコルを使用するＳＧＳＮ応答は、メンバシップ報告メッセージを伴う。
【００８６】
対応する各ＳＧＳＮにおける設定が分散型である場合、ＴＬＭＧ登録要求メッセージは省略される。ＧＧＳＮ及びＳＧＳＮにおいて設定を使用することも可能である。この場合、対応するシーケンスを同時に実行することもできる。また、図８のシグナリングを部分的に同時に実行することもできる。
【００８７】
どのＳＧＳＮがＴＬＭＧをサポートすることでＴＬＭＧの一部となっているかをＧＧＳＮが把握するために、必要に応じて、ＴＬＭＧ要求メッセージの肯定応答又は否定応答を使用してもよい。適用する多重化手順など、ＴＬＭＧ関連設定パラメータを取り決める際にも、ＴＬＭＧ登録要求手順を使用することができる。ＰＰＰネゴシエーションにおいて使用されるような汎用ネゴシエーションメカニズムを適用して、ＴＬＭＧに使用される共通の設定パラメータ群について同意することができる。ＳＧＳＮはＩＧＭＰメンバシップ報告メッセージを使用してサービスクラスベースＴＬＭＧに登録し、ＴＬＭＧ配信ツリーの一部を形成することができる。メンバシップ報告メッセージについては、必要なＱｏＳを考慮に入れてルーティングする。
【００８８】
ＴＬＭＧにおけるＭＣ−ｔｒａｆｆｉｃの多重化は様々な方法を用いて実行することができる。基本的に全ての多重化アルゴリズムを適用することができよう。多重化がネットワークにおいて共通でない場合、すなわち、全てのＳＧＳＮが必ずしも同じ多重化をサポートしていない場合、ＧＧＳＮとＳＧＳＮとの間で適用される多重化メカニズムのネゴシエーションが必要となるかもしれない。必要に応じて、ＧＧＳＮは異なるＳＧＳＮの多重化機能を備えるように設定される。言うまでもなく、ＴＬＭＧごとに１つの多重化処理の手法が使用されるべきである。幾つかの多重化メカニズムが適用可能な場合、ＴＬＭＧは、対応するＳＧＳＮにより適用・サポートされている多重化の種別をベースとすることができる。これは、事前に設定されたＴＬＭＧの確立処理中に考慮される必要がある。例えば、ＳＧＳＮが特定の種別の多重化をサポートしない場合、ＴＬＭＧ全体に対して多重化が変更されるか、専用のＴＬＭＧが確立されるか、あるいは、ＳＧＳＮがＴＬＭＧから除外され、ＳＧＳＮのユーザに対してユニキャストセッションが使用されることになろう。また、ＴＬＭＧを確立する前に、異なる設定をクエリーしてネゴシエートするために、シグナリングシーケンスを使用することができる。専用のＴＬＭＧとは、事前に設定され、そして事前に確立されたＴＬＭＧを考慮せずにユーザ要求に応じて確立されたＴＬＭＧを意味する。
【００８９】
図９を参照する以下の説明では、設定がＧＧＳＮで行なわれる場合におけるサービスクラスベースＴＬＭＧの解放処理を示している。この場合、ＧＧＳＮはＴＬＭＧ解放要求を対応するＳＧＳＮ、すなわち、ＳＧＳＮ１及びＳＧＳＮ２に送信することによって解放処理を開始する。対応するＳＧＳＮにおける設定が分散型である場合、ＴＬＭＧ解放要求メッセージは省略される。ＧＧＳＮ及びＳＧＳＮにおいて設定を同時に使用することも可能である。どのＳＧＳＮがＴＬＭＧから削除されたかをＧＧＳＮが把握するために、必要に応じて、ＴＬＭＧ解放メッセージの肯定応答及び否定応答を使用してもよい。
【００９０】
ＳＧＳＮは、ＴＬＭＧ配信ツリーから除外されるようにするため、ＩＧＭＰ脱退メッセージを使用してサービスクラスベースＴＬＭＧへの登録を解除する。ＩＧＭＰバージョン１には、明示的な脱退メッセージが存在しないため、グループから脱退するための適正なメカニズムが使用される。標準ＩＧＭＰメンバシップクエリーメッセージとは対照的に、ＳＧＳＮは以降の定期的なメッセージ送信を行なわないことによってＴＬＭＧから脱退することもできる。ＩＧＭＰバージョン１及びバージョン２をサポートするために、ＧＧＳＮはオプションのテーブルを保持することができる。このテーブルは、ＳＧＳＮがサポートするＩＧＭＰバージョンを反映するものである。
【００９１】
ＳＧＳＮをＴＬＭＧから削除した後、マルチキャスト配信ツリーが更新される。これは、マルチキャストルーティングプロトコルにより行なうことができる。
【００９２】
別の実施例では、ＧＧＳＮが登録手順を開始する場合、あらゆる可能なＴＬＭＧ／サービスクラス組み合わせを、ＴＬＭＧ登録要求メッセージで示してもよい。ＳＧＳＮは、登録したいＴＬＭＧに関して個別のＩＧＭＰメンバシップ報告メッセージをＧＧＳＮに送信する。また、特定の又は全てのＴＬＭＧについて登録するよう、ＧＧＳＮがＳＧＳＮに命令してもよい。
【００９３】
ＧＧＳＮは、ＰＬＭＮのマルチキャストグループメンバの総数のみならずＧＧＳＮに論理的に接続されるＳＧＳＮの台数に基づいて、特定のマルチキャストグループに対してＴＬＭＧが適用されるか否かを決定してもよい。このような決定は、ユーザがマルチキャストグループに登録する又はグループへの登録を解除するときには、いつでも進行中のマルチキャストセッション中に変更できるという意味において動的であってもよい。
【００９４】
以下の説明では、本発明の好適な実施例が示される。この実施例では、マルチキャストグループの登録処理を説明する。図１０に基づいて説明を行なう。
【００９５】
ＰＤＰコンテキストの活動化処理の後、ユーザはＩＧＭＰメンバシップ報告を使用することで、ＧＧＳＮ内の特定のマルチキャストグループに登録を行なう。ＧＧＳＮはローカルマルチキャストルータとして機能する。ＩＧＭＰ及びＭＬＤにおいて指定されるローカルマルチキャストルータとは異なり、ＧＧＳＮはアクティブなＰＤＰコンテキストを有する全てのユーザに対してメンバシップクエリーを送信する訳ではない。これを送信すれば、貴重な無線リソースを不必要に浪費することになるであろう。その代わりに、ユーザは単独でマルチキャストグループへの参加を開始する。これは、メンバシップクエリーメッセージにより要請されることなく、ユーザがメンバシップ報告メッセージにより自身のメンバシップを報告することを意味する。ＩＧＭＰの規定では、マルチキャストグループごとに１つのメンバだけがメンバシップを報告する。このため、ローカルマルチキャストルータには、対応マルチキャストグループの少なくとも１つのメンバがローカルネットワークに接続されていることしか分からない。ローカルマルチキャストルータは、いくつのメンバが接続しているかも、これらのメンバの身元も把握してはいない。しかし、各マルチキャストグループメンバが上述のように自身のメンバシップを報告する場合には、ＧＧＳＮ又は他のローカルマルチキャストルータは、マルチキャストグループごとのマルチキャストグループメンバの数のみならず、全てのグループメンバの身元についても情報を取得している。この情報は、効率化、課金、又は統計的な目的で使用することができる。また、ユーザ数と、サポートされるマルチキャストグループの一部であるＳＧＳＮの情報とを格納することも可能であり、ＧＧＳＮは、必要に応じて、対応するＳＧＳＮに情報を要求する。マルチキャストグループメンバを有する対応ＳＧＳＮの情報が格納されていない場合、ＴＬＭＧ自体を使用して全ての対象ＳＧＳＮに全メンバシップ要求をマルチキャストしてもよい。ＧＧＳＮは、グループメンバ数を考慮に入れ、ＴＬＭＧが効率的か否か、あるいは、複製されたユニキャストセッションを代わりに使用することが許容可能か否かを決定することができる。ＧＧＳＮはＩＧＭＰプロトコルを終了し、ＭＳのマルチキャストグループメンバシップについての情報を格納する。
【００９６】
必要に応じて、既存メッセージのうちの１つがメンバシップクエリーを含むように改訂されてもよい。これは、例えば、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GRPS), Service Description, Stage 2 (Release 1999)に規定されるように、ルータ通知メッセージに適用されてもよい。
【００９７】
ＩＧＭＰメンバシップ報告の受信後、ＧＧＳＮは必要に応じて検証を行ない、ユーザをマルチキャストグループに登録してもよいか否かを判定する。セキュリティチェックによりユーザのマルチキャストグループへの参加が許可されない可能性もあるし、グループの特性上、オペレータがマルチキャストグループ登録を許可しない可能性もあるし、あるいは、許容されたマルチキャストグループメンバが最大数に到達している可能性もある。ＧＧＳＮにおいて幾つかの他のチェック処理が実行されてもよい。判定結果が肯定的でない場合、ＧＧＳＮはメンバシップ報告拒絶メッセージをユーザに返信し、後述するシーケンスを実行しない。必要に応じて、ＧＧＳＮはメンバシップ報告拒絶メッセージの代わりにＩＣＭＰエラーメッセージをユーザに返信することもできる。
【００９８】
ホストが、閉じたグループの一部であるか否かを判定できるようにするために、ＧＧＳＮにおいて管理が行なわれてもよい。あるいは、ＧＧＳＮがマルチキャストグループを管理するサーバ又はデータベースへの外部インタフェースを有することもできる。
【００９９】
ＧＧＳＮは、マルチキャストグループに登録された移動局を有していることを、対応するＳＧＳＮに通知する。新規のＧＴＰメッセージが、ＳＧＳＮメンバシップ報告要求のために使用される。この目的で拡張ＰＤＵ通知メッセージを使用することも可能である。ＰＤＵ通知はＧＴＰ通知メッセージであり、例えば、TS 29.060. 3GPP TS 29.060 V.4.0.0 (2001 03) 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GRPS); GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface (Release 4)に規定されている。
【０１００】
ＴＬＭＧ確立手順の後、図８を参照して説明したように、複数の事前に設定されたＴＬＭＧがコアネットワークにおいて確立される。このコアネットワークでは、ＧＧＳＮがルートであり、ＳＧＳＮがツリーのリーフである。コアネットワークのＴＬＭＧを使用して外部のマルチキャストトラフィックがユーザに転送される。複数のマルチキャストグループが１つのＴＬＭＧ上へと多重化される場合、分離識別子が必要である。後述の図面では、Ｇｉインタフェースを介して受信される外部のマルチキャストグループのマルチキャストアドレスＭｃＡｄｄｒが、ＳＧＳＮでの分離処理に使用される。したがって、ＭｃＡｄｄｒがＳＧＳＮメンバシップ報告要求メッセージの形態でパラメータとして送信される。ＴＬＭＧについて多重化メカニズムが使用されない場合、マルチキャストグループのうちの１つだけがＴＬＭＧにマップされる。また、ＴＬＭＧのマルチキャストＩＰアドレスであるＴＬＭＧ−ＭｃＡｄｄｒが、新規のＧＴＰメッセージＳＧＳＮメンバシップ報告要求を伴って送信される。ＴＬＭＧ−ＭＣ Ａｄｄｒｅｓｓの使用は任意であり、メッセージにおける使用も任意である。また、ユーザのホストＩＤ、すなわち、マルチキャストグループに登録されたＭＳ−ＨｏｓｔＩＤはパラメータとしてこのメッセージを伴って送信される。
【０１０１】
実際、マルチキャスト・グループ・トラフィックにおいて、ＧＧＳＮは、ＰＤＰコンテキストの活動化中に、ＳＧＳＮによって既に確立されているＭＳ用のトンネルを無視し、代わりに事前に設定されたマルチキャスト配信ツリーを使用する。
【０１０２】
ＳＧＳＮメンバシップ報告要求メッセージの受信後、ＳＧＳＮはマルチキャストグループＭＣメンバシップ検証を行なう。特に、任意又は特定のマルチキャストグループに移動局を登録可能であるか否かを判定するために、ＳＧＳＮが加入チェック又は課金口座チェックを行なうことができることを意味する。検証の結果は、ＳＧＳＮメンバシップ報告結果メッセージに含まれる。検証結果が「否」の場合、ＳＧＳＮはＳＧＳＮメンバシップ報告結果メッセージをＧＧＳＮへと返信する。結果が否の場合には、マルチキャスト検証が失敗し、移動局がマルチキャストグループに参加すべきでないことを示す。原因の表示を伴うことができる。検証結果が「可」の場合、メッセージはＧＧＳＮに対して肯定的な結果を示す。さらに、ＳＧＳＮは、データを複製してマルチキャストデータストリームの受信時に、対応するホストに転送できるよう、Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓをユーザに対する既存のＰＤＰコンテキスト情報に加えることによって、ＭＣＡｄｄｒとＭＳ−ＨｏｓｔＩＤとの間の関係を記憶する。必要に応じて、使用されるＴＬＭＧのＴＬＭＧ−Ａｄｄｒｅｓｓも記憶される。
【０１０３】
ＴＬＭＧは事前に確立されているので、ＴＬＭＧのメンバであるＳＧＳＮの動的な更新及び検証は省略されても良い。
【０１０４】
ＳＧＳＮメンバシップ報告結果を受信すると、ＧＧＳＮはメンバシップ報告受諾又はメンバシップ報告拒絶を移動局へと返信する。このメッセージは、検証結果によっては原因の表示を含む。また、ＧＧＳＮは検証結果が肯定的の場合には何も返信せず、検証結果が否定的の場合にはＩＧＭＰエラーメッセージを返信しても良い。
【０１０５】
ＳＧＳＮメンバシップ報告結果が肯定的の場合、マルチキャストグループのユーザ数のカウンタが増分され、及び／又は、ＭＳ−ＨｏｓｔＩＤがマルチキャストグループ又はＴＬＭＧに追加される。
【０１０６】
ＧＧＳＮは、例えば、ＩＧＭＰメンバシップ報告を送信することによって、Ｇｉインタフェース上のバックボーンネットワークを介し、マルチキャストメンバシップの伝播の管理を行なう。隣接するルータへのメンバシップ伝播では、ＰＬＭＮなどのローカルネットワークの対応するマルチキャストグループ内にマルチキャストデータの受信を希望するメンバが少なくとも１つ存在することを通知するだけで良い。このため、ＰＬＭＮ内の第１のマルチキャストグループメンバに対してのみ、この伝播が必要とされる。マルチキャストグループがＧＧＳＮにおいて未知の場合、ＧＧＳＮはＧｉインタフェースを介してメンバシップ報告メッセージを次のマルチキャストルータへと伝播する。これにより、マルチキャストグループへと参加できるようになり、マルチキャストトラフィックを受信してマルチキャストグループの一部であるＰＬＭＮのＭＳｅｓへと当該トラフィックを転送できるようになる。ＧＧＳＮは、マルチキャストグループのユーザ数のカウンタ又はＭＳ−ＨｏｓｔＩＤの実際の数によりＧｉインタフェース上のメッセージを伝播すべきか否かを認識する。
【０１０７】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１１を参照してマルチキャストグループ登録解除処理及びＴＬＭＧの解放処理を説明する。
【０１０８】
先に説明したように、アクティブなＰＤＰコンテキストを有する全てのユーザには、定期的なメンバシップクエリーメッセージは送信されない。ＩＧＭＰバージョン１によれば、ローカルマルチキャストルータは、定期的にメンバシップクエリーメッセージをマルチキャストすることによって、ＬＡＮ上のマルチキャストグループにメンバが残存するか否かを判定する。ＩＧＭＰバージョン２では、脱退するメンバの待ち時間を削減するために脱退メッセージが定義されている。
【０１０９】
図１１において、移動局からのＩＧＭＰ脱退メッセージの受信時に、ＧＧＳＮは基本的なチェックを実行する。例えば、ＧＧＳＮは、移動局がマルチキャストグループの一部であったか否かをチェックする。ＧＧＳＮは新規のＧＴＰメッセージＳＧＳＮメンバシップ要求解放をＳＧＳＮへと送信し、移動局に対するメンバシップ解放を要求する。このメッセージは、パラメータとしてＴＬＭＧ ＭＣＡｄｄｒと移動局のアドレスＭＳ−ＨｏｓｔＩＤとを搬送する。ＳＧＳＮは、オプションの肯定メッセージＳＧＳＮメンバシップ解放ＡＣＫをＧＧＳＮへと返信することによって解放を確認し、対応するＴＬＭＧのリストから移動局を削除する。また、ＧＧＳＮは対応するマルチキャストアドレスのリストから移動局を削除するか、あるいは、対応するカウンタを減分する。
【０１１０】
必要に応じて、ＧＧＳＮは、ＳＧＳＮに係るマルチキャストグループ内のメンバの数が、ＳＧＳＮに対してマルチキャスト配信ツリーを使用するのに妥当ではなく、ＳＧＳＮのＴＬＭＧへの登録を解除すべきであると決定してもよい。これは、ＧＧＳＮからＳＧＳＮへと向かうオプションの情報要素Ａｃｔｉｏｎにより示される。パラメータＡｃｔｉｏｎはオプションである。データ配信を最適化するために使用されるべきである。このパラメータを使用することによって、ＧＧＳＮが過負荷の状況にあってもメッセージを使用することができる。
【０１１１】
ＧＧＳＮが、ＰＬＭＮの最後のマルチキャストグループメンバがマルチキャストグループへの登録を解除したと判定する場合、この情報はＧｉインタフェースを介して隣接するルータへと伝播される。ＩＧＭＰバージョン２又はそれ以降のバージョンが使用される場合、ＧＧＳＮはＩＧＭＰ脱退メッセージを送信する。バージョン２又はそれ以降のバージョンが使用されない場合、ＧＧＳＮはＧｉインタフェース上のマルチキャストグループメンバシップの更新処理を行なわない。
【０１１２】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１２を参照してＰＤＰコンテキストの非活動化処理を説明する。
【０１１３】
ＳＧＳＮ及びＧＧＳＮの少なくとも一方が、ＰＤＰコンテキストの非活動化処理を開始する。ＰＤＰコンテキストの非活動化には、２つのシグナリングメッセージ、すなわち、ＰＤＰコンテキスト削除要求及びＰＤＰコンテキスト削除応答が含まれる。非活動化を開始するノードは、ＰＤＰコンテキスト削除要求を送信し、応答としてＰＤＰコンテキスト削除応答を受信する。この手順は、3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)及び3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に詳細に記載されている。
【０１１４】
ＰＤＰコンテキスト非活動化処理の実行後、マルチキャストグループの登録解除処理と同様の、対応するシグナリングメッセージを伴う手順が適用される。ＳＧＳＮは移動局が１以上のＴＬＭＧの一部であったか否かをチェックする。チェック結果に従って、ＴＬＭＧ又は複数の対応するＴＬＭＧから移動局が削除される。その対応する１つ又は複数のＴＬＭＧにとって最後の移動局であったか否かによって、ＳＧＳＮはＴＬＭＧへの登録を解除することもある。
【０１１５】
マルチキャストグループ又はＴＬＭＧごと（いわゆるＭＣ−ｇｒｏｕｐ／ＴＬＭＧ）に格納された全てのＭＳ−ＨｏｓｔＩＤを有する場合、移動局が１以上のマルチキャストグループの一部であるか否かを、ＧＧＳＮがチェックし、その結果に従って動作することもできる。全てのＭＳ−ＨｏｓｔＩＤを有しない場合、ＳＧＳＮは、ＭＳ−ＨｏｓｔＩＤ及びＭｕｌｔｉｃａｓｔＧｒｏｕｐ／ＴＬＭＧを指定する新規の情報要素により、ＰＤＰコンテキスト削除要求メッセージ又はＰＤＰコンテキスト削除応答メッセージの形態で、ＧＧＳＮに通知する。あるいは、ＳＧＳＮからＧＧＳＮへの通知には、ＳＧＳＮメンバシップ解放に関して図１２に示されるのと同様の情報要素を伴う新規のメッセージが使用される。このメッセージは、ＧＧＳＮがＭＣ−ｇｒｏｕｐ／ＴＬＭＧごとに格納されたＭＳ−ＨｏｓｔＩＤを有する場合に使用可能であろう。ＴＬＭＧは、ＳＧＳＮにおいても、ＳＧＳＮメンバシップ解放メッセージにおいても任意のものである。
【０１１６】
上述のようなＳＧＳＮメンバシップ解放メッセージ又はそれに類するメッセージの受信時に、前述のマルチキャストグループ登録解除シーケンスで説明したのと同様の処理が適用される。ＰＤＰコンテキストの非活動化の後、前述のＩＧＭＰ脱退メッセージを使用することによって、マルチキャストグループ登録解除と同様の処理が適用される。ＭＳが１つ以上のマルチキャストグループの一部であったか否かを、ＳＧＳＮがチェックする。グループの一部である場合、ＭＳはこの１以上のマルチキャストグループから削除される。
【０１１７】
以下の説明では、本発明の好適な実施例が示される。この実施例では、移動局が在圏ＳＧＳＮエリアを変更する場合の手順を説明する。
【０１１８】
移動局が在圏ＳＧＳＮを変更する場合、ＳＧＳＮ及びＧＧＳＮに格納されたマルチキャスティング情報は、それに従って変更しなければならない。ＴＬＭＧも更新する必要が生じるかもしれない。
【０１１９】
3GPP TS 03.60 V7.5.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Digital cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1998)及び3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)に記載されているように、ＭＳはＧＰＲＳ位置情報登録処理（Attach）、ＳＧＳＮ間ルーティングエリア更新処理、又は在圏無線ネットワークサブシステム再配置処理によって、在圏ＳＧＳＮを変更することができる。
【０１２０】
ＧＰＲＳ位置情報登録は、3GPP TS 23.060 V3.6.0 (2001 01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release 1999)及びセクション６．１３．２のthe Inter SGSN Inter System Changeを含む同文書のセクション６．９．１．２．２のthe Inter SGSN Routing Area Updateに記載されている。The Serving SRNS Relocationは同文献のセクション６．９．２．２．１において見出される。
【０１２１】
しかし、ＧＰＲＳ位置情報登録を実行するときには、移動局はマルチキャストグループに登録されないので、マルチキャスティングではこの手順を考慮する必要がない。ＰＤＰコンテキストの削除処理の実行によって、対応するマルチキャストグループへの移動局の登録は、既に解除されているからである。
【０１２２】
ＳＧＳＮ間ルーティングエリア更新処理又は在圏ＳＲＮＳ再配置処理の場合、新規のＳＧＳＮはＰＤＰコンテキスト更新要求をＧＧＳＮへと送信する。
【０１２３】
ＳＧＳＮがマルチキャストグループメンバに対して変更される場合、ＳＧＳＮ及びＧＧＳＮにおけるマルチキャストの管理に関して３つの基本的な代替方法がある。
【０１２４】
第１の代替方法では、上述のように、以前のＳＧＳＮに対するマルチキャストグループ登録解除及びＴＬＭＧ解放と、新規のＳＧＳＮ手順に対するマルチキャストグループ登録及びＴＬＭＧ確立とが組み合わされる。以下の説明は図１０に基づいて行なわれる。
【０１２５】
上述したＰＤＰコンテキストの非活動化処理と同様に、ＳＧＳＮは、改良されたＰＤＰコンテキスト更新メッセージシグナリングを用いて、移動局がマルチキャストグループの一部であることをＧＧＳＮに通知する必要があるかもしれない。このシーケンスにおいて、ＧＧＳＮはＴＬＭＧの識別子についての通知を受信しなければならない。以前のＳＧＳＮ及び新規のＳＧＳＮに対して変さらについて通知するのはＧＧＳＮの機能である。以前のＳＧＳＮとは、移動局が登録されていたＳＧＳＮを意味し、新規のＳＧＳＮは移動局が現在処理されているＳＧＳＮである。以前のＳＧＳＮは、ＳＧＳＮメンバシップ解放要求メッセージにより通知される。処理担当となるＳＧＳＮの変さらについての確認応答として、以前のＳＧＳＮがＳＧＳＮメンバシップ解放Ａｃｋを送信する。以前のＳＧＳＮが最後の移動局を解放した場合、ＩＧＭＰ脱退メッセージが送信される。
【０１２６】
新規のＳＧＳＮにおけるマルチキャストメンバシップ検証処理はオプションである。ＧＧＳＮは、ＳＧＳＮメンバシップ報告要求メッセージ中の追加の識別子を使用して、これらのチェックが行なわれるべきか否かを判定してもよい。チェックが行なわれない場合、ＳＧＳＮメンバシップ報告結果を送信することによって、ＧＧＳＮに確認応答を通知すれば良い。あるいは、信頼性の高い通信の場合には、ＧＧＳＮに全く報告しなくても良いだろう。追加のマルチキャストメンバシップ検証が実行される場合、ＧＧＳＮは否定的な結果を移動局へと送信しなければならないかもしれない。この場合、ＳＧＳＮはＴＬＭＧへの登録を解除する必要があるだろう。ＰＬＭＮはマルチキャストグループへの登録を解除しなければならないかもしれない。なお、これらのメッセージシーケンスは図１３において省略されている。
【０１２７】
第２の代替方法では、ＰＤＰコンテキスト更新処理の実行後にマルチキャスト情報メッセージを送信することによって、以前のＳＧＳＮから新規のＳＧＳＮへとマルチキャストグループ情報が直接的に転送される。これは図１４に開示される通りである。以前のＳＧＳＮは、ＳＧＳＮメンバシップ解放によって、ＧＧＳＮにおけるエントリの削除を開始する。続いて、ＩＧＭＰ脱退メッセージが送信される。ＳＧＳＮは必要に応じて検証処理を行なっても良く、その結果に応じて、ＳＧＳＮメンバシップ報告をＧＧＳＮへと送信するのを回避しても良い。この場合、拒絶メッセージを移動局に送信することを、ＳＧＳＮはＧＧＳＮに報告するであろう。従って、第２の方法でも、第１の方法と同じ原理を適用することができる。
【０１２８】
第３の代替方法では、マルチキャスト情報メッセージを以前のＳＧＳＮから受信した後で、ＧＧＳＮにおける以前のＳＧＳＮ及び新規のＳＧＳＮについてのマルチキャストエントリを更新するために、新規のＳＧＳＮが更新メッセージであるマルチキャストＳＧＳＮ変更情報をＧＧＳＮに送信する場合の簡単な解決法を開示している。このシグナリングメッセージの交換も図１５に示している。
【０１２９】
３つの方法の全てにおいて、以前のＳＧＳＮ及び新規のＳＧＳＮの双方に関して、マルチキャスト・ルーティング・プロトコルにより最終的にＴＬＭＧが更新される。
【０１３０】
第２の方法及び第３の方法では、以前のＳＧＳＮから新規のＳＧＳＮへのマルチキャスト情報転送は、新規のＳＧＳＮとＧＧＳＮとの間にＰＤＰコンテキスト更新を送信する前に行なわれても良い。ＰＤＰコンテキスト更新についてのメッセージ交換処理は、マルチキャスト情報を伴うように拡張されても良い。
【０１３１】
３つの方法の全てにおいて、新規のＳＧＳＮが実施した検査処理によって、マルチキャストグループメンバシップを受諾しないとなった場合には、追加のメッセージが移動局に送信されても良い。例えば、新規のＳＧＳＮがマルチキャストルーティングプロトコルをサポートしない、あるいは、マルチキャスト情報交換メッセージ又はマルチベンダ環境などの情報要素をサポートしない場合にこれが当てはまるかもしれない。ＭＳは、登録解除を行なうためにＩＧＭＰ脱退メッセージをＧＧＳＮに送信するように命令される。
【０１３２】
以下の説明では、ＴＬＭＧ上でのマルチキャスト・ストリーム・データの多重化を説明する。
【０１３３】
Ｇｉインタフェースに到着する全てのマルチキャスト・グループ・トラフィックに対して、限られた数のＴＬＭＧを使用することによって、マルチキャストストリームはコアネットワークにおいて暗黙的に多重化される。事前に設定されたＴＬＭＧ上でマルチキャストストリームを多重化するには幾つかの方法がある。説明される多重化手法は、ＴＬＭＧが事前設定でなく、必要に応じて確立される場合にも適用することができる。
【０１３４】
以下の説明では、多重化を実行する幾つかの方法が提示される。
【０１３５】
コアネットワークにおけるマルチキャスティングはＰＬＭＮ特有のマルチキャストアドレスに基づいているため、ＩＰパケットヘッダ中のオリジナルのマルチキャスト宛先アドレスは変換されるべきである。オリジナルのＩＰマルチキャストアドレスは、プライベート拡張ヘッダとしてＩＰパケットヘッダに加えられる。
【０１３６】
ＩＰｖ６ではこれが可能であり、ＩＰヘッダフィールドの次のヘッダとしてＩＰを指定することによって、追加のルーティングヘッダを加えることができる。このルーティングヘッダ中のＩＰアドレスもＩＰ−Ｍｕｌｔｉｃａｓｔアドレスである。これは、Ｇｉインタフェース上で受信した最初のＩＰマルチキャストアドレスであることを意味する。分離化処理は、宛先Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ又はＭｕｌｔｉｃａｓｔ Ｐｏｒｔに基づいて、ＳＧＳＮにおいて実行される。ＩＰヘッダ中のポート番号に基づいて、異なるアプリケーションを識別することができる。これは、同じ宛先アドレスに所属する、異なるアプリケーションに対して指定される複数のマルチキャストデータストリームを、同一のＴＬＭＧ上で多重化することができ、各ストリームの区別はポートアドレスにより行なわれることを意味する。このため、ＳＧＳＮは移動局ＩＤに対応するマルチキャストアドレス又はマルチキャストポートのテーブルを保持する必要がある。
【０１３７】
別の方法では、ＳＧＳＮにおいてマルチキャストストリームを分離するために、ＧＴＰトンネリングＩＤであるＴＩＤを使用することができる。この場合、Digital cellular Telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Point To Multipoint Multicast Service Description; Stage 2; GSM 03.61, 15th January 1997, Version 0.7.1に記載されているようなＧＴＰ−Ｕの拡張バージョンが使用される。ＳＧＳＮは、ＴＩＤと移動局ＩＤとの関連付けを記憶するテーブルを保持する必要がある。この方法が使用される場合、マルチキャストアドレスはＴＩＤにより置換される。マルチキャストアドレスの代わりとしてのＴＩＤを送信できるようにするためには、シグナリングシーケンスを改訂する必要があろう。
【０１３８】
以下の説明では、本発明の好適な実施例が示される。この実施例では、図１６を参照してマルチキャストデータ配信手順を説明する。
【０１３９】
図１６は、マルチキャストデータがＧＧＳＮで受信され、受信されたマルチキャストデータを、ＴＬＭＧを介してそれぞれ複数のグループメンバが接続されている２台のＳＧＳＮへと転送するシナリオを示している。
【０１４０】
複数のＴＬＭＧは、ＵＭＴＳサービスクラスごとに存在してもよいので、元のマルチキャストアドレスは、前述のようにＴＬＭＧを介してＳＧＳＮに転送されるマルチキャストストリーム内に搭載されて搬送されなければならない。この元のマルチキャストアドレスは、ＳＧＳＮ内の１つのＴＬＭＧ上に存在する、異なるマルチキャストフローを分離するために必要となる。ＧＧＳＮは、以下の基準のうち、１以上を考慮することによって特定のマルチキャストセッションに使用されるＴＬＭＧを判定する。例えば、ＩＰヘッダのサービス種別ビットなどに従って、Ｇｉインタフェース上で受信されるマルチキャストストリーム内で示されている必要なＱｏＳが考慮される。必要なＱｏＳは、ポリシー実行ポイント、ポリシー決定ポイント、又は呼状態制御機能（ＣＳＣＦ）など、外部のエンティティによっても通知することができる。さらに、デフォルト又は既知のマルチキャストアドレスに対する所要のサービスクラスの設定を考慮に入れてもよい。
【０１４１】
マルチキャストデータストリームを受信すると、ＧＧＳＮは、テーブル中でアプリケーション・レベル・マルチキャスト・アドレスに属するＴＬＭＧアドレスを検索する。この検索の際に、必要に応じてＱｏＳを考慮に入れる。ＧＧＳＮは、ＩＰ宛先アドレスをＴＬＭＧマルチキャストアドレスへと変更し、元のマルチキャストアドレスを拡張情報としてＩＰパケットヘッダへと加え、ＴＬＭＧの一部である全てのＳＧＳＮに対してデータをマルチキャストする。上述した他の多重化メカニズムの１つが使用される場合、元のＩＰマルチキャストアドレスのカプセル化は異なる方法で実行される。
【０１４２】
ＳＧＳＮにおいてＴＬＭＧマルチキャストデータを受信すると、このＳＧＳＮはＩＰ宛先アドレスフィールド又はＴＬＭＧで指定されるような元のＩＰマルチキャストアドレスを取り出し、テーブル検索のためにこれを使用して対応するマルチキャストグループメンバを識別する。ＩＰ宛先アドレスはこの元のマルチキャストアドレスへと戻される。ＳＧＳＮはデータを複製し、ユニキャスト伝送又はマルチキャスト技術を使用し、無線アクセスネットワークを介してデータを各移動局へと転送する。マルチキャストグループに対してグループメンバを持たない場合、ＳＧＳＮはマルチキャストデータを無視する。
【０１４３】
以下の説明では、各実施例が提示される。これらの実施例では、例えば、ＳＧＳＮのような在圏ノードがＴＬＭＧの一部となることを決定する。
【０１４４】
必要に応じて、ＳＧＳＮは、ＭＳｅｓに対して中継するマルチキャストデータパケットの個数と、破棄するマルチキャストデータパケットの個数とについての統計値を収集する。これは、ＳＧＳＮには対応するマルチキャストグループの一部である移動局が存在しないためである。多重化により得られるよりもマルチキャストトラフィックを破棄するためにより高い処理能力を必要とするので、ＳＧＳＮはこの情報に基づいてＴＬＭＧへの登録の解除を決定しても良い。ＧＧＳＮは、ＴＬＭＧの一部でないＳＧＳＮのリストを格納しなければならない。これらは、マルチキャストトラフィックを受信することはない。その代わりに、ＧＧＳＮ内のマルチキャストトラフィックを複製することによってサービスの提供を受け、これらのＳＧＳＮに対してユニキャスト伝送を使用する。
【０１４５】
マルチキャスト率の評価は、ＳＧＳＮがＴＬＭＧの一部となることを決定するための一例である。他の例としては、地理的な座標に基づくＴＬＭＧが挙げられる。これは、例えば、国又は都市の一部などの地理的エリアをカバーする全てのＳＧＳＮにまたがっているＴＬＭＧを意味する。このようなＴＬＭＧは、天気予報、交通情報、又は娯楽情報などの地理的座標に関連するマルチキャストサービスを提供するのに使用されてもよい。
【０１４６】
上述の事前に設定されたＴＬＭＧ及び対応するマルチキャスト配信ツリーを使用して、ＵＭＴＳ内でのブロードキャストサービスを実現することもできる。関係するノードのみならず全てのノードがブロードキャストコンテンツを受信するので、ネットワークレベルでのブロードキャスティングは避けるべきである。複数のサービスプロバイダにより使用されるマルチサービスバックボーンネットワークの場合、全てのノードがコンテンツを受信する事態は避けるべきである。
【０１４７】
専用のＴＬＭＧ登録セキュリティ手順は、各ノードがＴＬＭＧに登録可能である場合についての手順である。この場合、各ノードの登録には専用のセキュリティ手順が必要とされるであろう。事前に設定されたＴＬＭＧの場合、例えば、ＧＧＳＮで設定が実行されると、自動的に１回の動作でＴＬＭＧ全体の安全を保証することができる。
【０１４８】
事前に設定されたＴＬＭＧの概念により、ネットワークの専用のノード群へのマルチキャストサービス及びブロードキャストサービスの提供が可能になる。特に、Ｇｐインタフェースでは、設定、管理などの関連情報のブロードキャスティング又はマルチキャスティングは、ＴＬＭＧにより経済的に処理されるようにしてもよいだろう。
【０１４９】
ブロードキャストされるデータストリームごとに、１つの事前に設定されたＴＬＭＧが確立又は選択される。このＴＬＭＧはＧＧＳＮに接続される全てのＳＧＳＮを含む。
【０１５０】
本願の開示では、ＧＰＲＳ／ＵＭＴＳに対する解決法を説明する。しかしながら、ＲＴＳＰを有するポイント・ツー・マルチポイントストリーミング又はＳＩＰを有する会話型マルチメディアサービスに対して、マルチキャスト・トランスポート・グループを作成するために、同様のメカニズムを適用できることは理解されるべきである。
【０１５１】
本願に記載される解決法は、異なるネットワークエンティティ間での情報交換をカバーしている。データ記憶装置は様々な方法で分散させてもよく、同一又は異なる情報の搬送手段として他のメッセージが使用されてもよいことは理解されるべきである。
【０１５２】
上述のシグナリングシーケンスにおける各メッセージにおいて、コネクション指向のアプローチが使用されている場合には、一部の情報要素が省略されてもよい。さらに、例えば、ＧＴＰメッセージなど、幾つかの新しい専用メッセージの代わりに、付加的な作用を有する共通のメッセージが使用されてもよい。
【０１５３】
この報告におけるシグナリングシーケンスは、信頼性の高い伝送をベースとしている。信頼性の低い伝送の場合、シーケンスはそれに適合するように、すなわち、確認メッセージ又は肯定応答メッセージを加えるよう、変更されなければならないだろう。
【０１５４】
さらに、この発明でカバーされる解決法は、ＧＳＭ又はＵＭＴＳネットワークのパケット交換ドメインに焦点を当てている。一般的に、この考えは、ＧＴＰ、Ｌ２ＴＰ、ＩＰＳｅｃ、Ｍｏｂｉｌｅ ＩＰなどのトンネリングが使用される際に適用することができる。従って、本発明は、２つのＩＰレイヤ、すなわち、アプリケーションＩＰレイヤ及びトランスポートＩＰレイヤを有するネットワークに適用することができる。また、トランスポートレイヤがＡＴＭなどのマルチキャスト伝送をサポートする別の技術に基づく場合には、各メカニズムを適用することができる。
【図面の簡単な説明】
【０１５５】
【図１】図１は、ＵＭＴＳネットワーク、無線ネットワーク、及びＩＰマルチメディアサブシステムにおけるパケット交換ドメインを示す図である
【図２】図２は、本発明に係る基本的概念のネットワークの関連図である。
【図３】図３は、ＵＭＴＳユーザプレーン用のプロトコルスタックの概要を示す図である。
【図４】図４は、本発明の基本的概念のプロトコル関連図である。
【図５】図５は、事前に設定されたトランスポートレベルのマルチキャストグループトンネルを示す本発明の基本的概念を示す図である。
【図６】図６は、事前に設定されたトランスポートレベルのマルチキャストグループトンネル上での多重化を示す本発明の基本的概念を示す図である。
【図７】図７は、本発明に係る各エントリの管理用のデータ構造を示す図である。
【図８】図８は、事前に設定されたＴＬＭＧ確立手順を示す図である。
【図９】図９は、事前に設定されたＴＬＭＧ解放手順を示す図である。
【図１０】図１０は、マルチキャストグループ登録手順を示す図である。
【図１１】図１１は、マルチキャストグループ登録解除手順を示す図である。
【図１２】図１２は、ＰＤＰコンテキストの非活動化を示す図である。
【図１３】図１３は、ＳＧＳＮを変更する手順を実行する第１の代替方法を示す図である。
【図１４】図１４は、ＳＧＳＮを変更する手順を実行する第２の代替方法を示す図である。
【図１５】図１５は、ＳＧＳＮを変更する手順を実行する第３の代替方法を示す図である。
【図１６】図１６は、マルチキャストデータ配信ツリーを示す図である。
Claims (27)
- 少なくとも１台のルータと、少なくとも１つのユーザについて処理する少なくとも１台の在圏ノードとを有する通信ネットワークにおいて、複数のマルチキャストグループに係る複数のマルチキャストデータストリームについてマルチキャスト伝送を実行する方法であって、
−事前に設定されたトランスポートレベルのマルチキャストグループトンネルは、トンネリング用のトランスポートレイヤプロトコルによって事前に確立され、前記ルータと前記在圏ノードとの間のマルチキャストグループに割り当てられ、
−前記ルータは、事前設定に合致する前記複数のマルチキャストデータストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化するように構成され、
−マルチキャストデータの伝送は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを介して前記ルータから前記在圏ノードに対して実行され、
−前記在圏ノードは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で受信されるマルチキャストデータストリームを非多重化するように構成され、
−マルチキャストデータストリームの伝送は、前記在圏ノードから、前記マルチキャストグループに登録された前記少なくとも１つのユーザへと実行されることを特徴とする方法。 - 前記マルチキャストグループに登録されるユーザが２以上存在する場合、前記複数のマルチキャストデータストリームの複製は前記在圏ノードで実行されることを特徴とする請求項１に記載の方法。
- 前記トランスポートレベルのマルチキャストグループトンネルの事前設定は、複数の異なるサービスクラスに従って実行されることを特徴とする請求項１又は２に記載の方法。
- 事前設定は複数の異なる地理的領域を考慮して実行されることを特徴とする請求項１、２又は３の何れかに記載の方法。
- 前記在圏ノードは、前記ルータに対して事前に設定されたトランスポートレベルのマルチキャストグループへのコネクション又は前記グループからの解放に対する関心を通知することを特徴とする請求項１ないし４の何れかに記載の方法。
- 前記ルータは、管理インタフェースにより事前に設定されたトランスポートレベルのマルチキャストグループへと接続する又は前記グループから解放される前記在圏ノードを管理することを特徴とする請求項１ないし５の何れかに記載の方法。
- 前記ルータと少なくとも１台の前記在圏ノードとの間に、事前に設定されたマルチキャスト配信ツリーが作成されることを特徴とする請求項１ないし６の何れかに記載の方法。
- 前記事前に設定されたマルチキャスト配信ツリーは、複数のマルチキャストルーティングプロトコルにより確立されることを特徴とする請求項７に記載の方法。
- 複数のマルチキャストグループが同じサービスクラスに属する場合、これら複数のマルチキャストグループについての多重化が、前記サービスクラスをサポートする同一の事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で実行されることを特徴とする請求項１ないし８の何れかに記載の方法。
- 前記事前に設定されたトランスポートレベルのマルチキャストグループと、前記マルチキャストグループの登録ユーザと、前記マルチキャストグループのマルチキャストアドレスとの関連付けを管理する管理用のデータ構造は、ポイントツーポイント指向のネットワーク内で分散管理または集中管理されることを特徴とする請求項１又は９に記載の方法。
- 前記データ構造は、前記ルータ及び前記在圏ノードの少なくとも一方で管理されることを特徴とする請求項１０記載の方法。
- 前記データ構造は、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記サービスクラスとの間の関係付けを含むことを特徴とする請求項９又は１１記載の方法。
- 前記在圏ノードは、ユーザに対して中継するマルチキャストデータパケットの個数と破棄するマルチキャストデータパケットの個数とについての統計値を収集し、その収集結果に基づいて、事前に設定されたトランスポートレベルのマルチキャストグループへの登録を解除するかどうかが決定されることを特徴とする請求項１ないし１２の何れかに記載の方法。
- 前記ルータは、登録された在圏ノードの台数を管理することを特徴とする請求項９ないし１３の何れかに記載の方法。
- 同一の事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で受信中の多重化された複数のデータストリームを分離するために、前記在圏ノードは、前記登録されたユーザを有するサービス中のマルチキャストグループのリストを管理することを特徴とする請求項９ないし１４の何れかに記載の方法。
- ユーザのマルチキャストグループへの登録又はマルチキャストグループへの登録解除を実行するために、ユーザは、前記ルータに通知し、前記ルータは、前記在圏ノードに通知し、前記データ構造中の対応するエントリの更新が実行されることを特徴とする請求項１ないし１５の何れかに記載の方法。
- ユーザが前記在圏ノードを変更する場合、新規の在圏ノードへのユーザの登録、以前の在圏ノードからのユーザの削除、及び前記ルータ中の前記対応するエントリの更新が実行されることを特徴とする請求項１ないし１６の何れかに記載の方法。
- 前記トンネリング用のトランスポートレイヤプロトコルは制御シグナリングプロトコルであることを特徴とする請求項１ないし１７の何れかに記載の方法。
- 前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立または解放するために、前記制御シグナリングプロトコルのメッセージが交換されることを特徴とする請求項１ないし１８の何れかに記載の方法。
- 前記制御シグナリングプロトコルは、ＧＴＰプロトコルであることを特徴とする請求項１９に記載の方法。
- ＧＴＰトンネリングＩＤ（ＴＩＤ）は、前記在圏ノード中の前記複数のマルチキャストストリームを分離するために使用されることを特徴とする請求項２０に記載の方法。
- 前記マルチキャストは、ＩＰマルチキャストアドレスを有する複数のＩＰパケットを使用するＩＰマルチキャストであることを特徴とする請求項１ないし２１の何れかに記載の方法。
- マルチキャストグループへの登録及びマルチキャストグループからの解放について情報伝達は、ＩＧＭＰ又はＭＬＤプロトコルにより実行されることを特徴とする請求項１ないし２１の何れかに記載の方法。
- 前記ノード、及び少なくとも１つのユーザを処理する少なくとも１台の在圏ノードのうち、少なくとも一方を有する通信ネットワークにおいて、複数のマルチキャストグループ係る複数のマルチキャストデータストリームについてのマルチキャスト伝送を
−前記在圏ノードに対して事前に設定されたトランスポートレベルのマルチキャストグループトンネルを確立するための論理手段と、
−複数のマルチキャストデータストリームを前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルへと多重化するための論理手段と、
−マルチキャストデータを前記事前に設定されたトランスポートマルチキャストグループトンネルを介して前記在圏ノードへと転送するための論理手段とを用いて実行するように構成されたルータ。 - 前記ルータは、前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと、前記マルチキャストグループの登録ユーザと、前記マルチキャストグループのマルチキャストアドレスとの関連付けを管理する管理用のデータ構造を制御することを特徴とする請求項２３に記載のルータ。
- 少なくとも１台のノードと、少なくとも１つのユーザを処理する少なくとも１台の在圏ノードとを有する通信ネットワークにおいて、複数のマルチキャストグループに係る複数のマルチキャストデータストリームについてのマルチキャスト伝送を
−前記事前に設定されたトランスポートマルチキャストグループトンネル上で前記ルータから複数のマルチキャストデータストリームを受信するための論理手段と、
−前記事前に設定されたトランスポートレベルのマルチキャストグループトンネルと対応するマルチキャストグループに登録されたユーザとを管理するための論理手段と、
−前記事前に設定されたトランスポートレベルのマルチキャストグループトンネル上で多重化された複数のマルチキャストデータストリームを分離するための論理手段と、
−前記対応するマルチキャストグループに登録された前記ユーザ間で前記複数の受信されたマルチキャストデータストリームを複製するための論理手段とを用いて実行するように構成された在圏ノード。 - 少なくとも１台のルータと、複数のユーザを処理する少なくとも１台の在圏ノードとを有するポイントツーポイント指向のパケット交換通信ネットワークにおいて、複数のマルチキャストグループに係るマルチキャストを実行するように構成されるシステムであって、
請求項２６に記載された複数の在圏ノードと通信を行ない、請求項１に記載された方法を実行する請求項２４に記載された少なくとも１台のルータを含むことを特徴とするシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP01115456 | 2001-06-27 | ||
| PCT/EP2002/006827 WO2003003650A2 (en) | 2001-06-27 | 2002-06-20 | Multicast in point-to-point packet-switched oriented networks |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004531179A true JP2004531179A (ja) | 2004-10-07 |
| JP2004531179A5 JP2004531179A5 (ja) | 2006-01-05 |
| JP3942033B2 JP3942033B2 (ja) | 2007-07-11 |
Family
ID=8177833
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003509703A Expired - Lifetime JP3942033B2 (ja) | 2001-06-27 | 2002-06-20 | ポイントツーポイントパケット交換向きのネットワークにおけるマルチキャスト方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8098618B2 (ja) |
| EP (1) | EP1400057B1 (ja) |
| JP (1) | JP3942033B2 (ja) |
| AT (1) | ATE303025T1 (ja) |
| AU (1) | AU2002351954A1 (ja) |
| DE (1) | DE60205748T2 (ja) |
| WO (1) | WO2003003650A2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011510590A (ja) * | 2008-01-25 | 2011-03-31 | エスイーエイエイチ ネットワークス カンパニー リミテッド | ＷｉＭＡＸにおけるマルチキャストブロードキャストサービス（ＭＢＳ）支援方法及び装置 |
| JP2011125029A (ja) * | 2003-03-12 | 2011-06-23 | Orange Sa | 電気通信 |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7903593B2 (en) | 2001-08-23 | 2011-03-08 | Runcom Technologies Ltd. | Multicast transmission in packet based cellular networks |
| US20040022226A1 (en) * | 2002-07-31 | 2004-02-05 | Peter Edlund | Subscribe-notify function between PLMN nodes |
| US7653012B2 (en) * | 2002-09-26 | 2010-01-26 | Sharp Laboratories Of America, Inc. | Relay transmission of data in a centralized network |
| US7835365B2 (en) * | 2002-09-26 | 2010-11-16 | Sharp Laboratories Of America, Inc. | Connection management in a centralized communication system |
| US20040081089A1 (en) * | 2002-09-26 | 2004-04-29 | Sharp Laboratories Of America, Inc. | Transmitting data on scheduled channels in a centralized network |
| US7961736B2 (en) * | 2002-09-26 | 2011-06-14 | Sharp Laboratories Of America, Inc. | Convergence and classification of data packets in a centralized communication system |
| US20040131023A1 (en) * | 2003-01-03 | 2004-07-08 | Otso Auterinen | Communications system and method |
| IL154739A0 (en) * | 2003-03-04 | 2003-10-31 | Bamboo Mediacasting Ltd | Segmented data delivery over non-reliable link |
| IL157886A0 (en) * | 2003-09-11 | 2009-02-11 | Bamboo Mediacasting Ltd | Secure multicast transmission |
| IL157885A0 (en) * | 2003-09-11 | 2004-03-28 | Bamboo Mediacasting Ltd | Iterative forward error correction |
| IL158158A (en) | 2003-09-29 | 2012-05-31 | Bamboo Mediacasting Ltd | Distribution of multicast data to users |
| US20050079858A1 (en) * | 2003-10-09 | 2005-04-14 | Rosen Eric C. | Method and apparatus for restricting media communication in a communication network |
| US20060029074A2 (en) * | 2004-02-09 | 2006-02-09 | Packethop, Inc. | ENHANCED MULTICASE FORWARDING CACHE (eMFC) |
| EP1645072B1 (en) * | 2004-06-04 | 2007-08-08 | Siemens Aktiengesellschaft | Dynamic and traffic-driven optimization of message routing to geographical addresses |
| US7512085B2 (en) * | 2004-06-24 | 2009-03-31 | International Business Machines Corporation | Method for multicast tunneling for mobile devices |
| JP2006042223A (ja) * | 2004-07-30 | 2006-02-09 | Hitachi Communication Technologies Ltd | パケット転送装置 |
| MX2007001930A (es) * | 2004-08-16 | 2007-04-23 | Qualcomm Flarion Tech | Metodo y aparatos para administrar miembros de un grupo para comunicaciones grupales. |
| US7630328B2 (en) * | 2004-08-18 | 2009-12-08 | At&T Intellectual Property, I,L.P. | SIP-based session control |
| US7626950B2 (en) * | 2004-08-18 | 2009-12-01 | At&T Intellectual Property, I,L.P. | SIP-based session control among a plurality of multimedia devices |
| US7937485B2 (en) * | 2004-08-31 | 2011-05-03 | At&T Intellectual Property I, L.P. | Streaming gateway |
| EP1684459A1 (de) * | 2005-01-25 | 2006-07-26 | Siemens Aktiengesellschaft | Rundfunk zu einem mobilen Kommunikationsendgerät mit Rückkanalführung durch ein drahtloses Netzwerk |
| US7656886B2 (en) * | 2005-02-07 | 2010-02-02 | Chin-Tau Lea | Non-blocking internet backbone network |
| US8730985B2 (en) | 2005-03-15 | 2014-05-20 | Time Warner Cable Enterprises Llc | Technique for providing on a program channel composite programming content attributed to different sources |
| US7653044B1 (en) * | 2005-04-07 | 2010-01-26 | Marvell Israel (M.I.S.L.) Ltd. | Address scope checking for internet protocol version 6 |
| US20070019645A1 (en) * | 2005-07-05 | 2007-01-25 | Deepthy Menon | Method and system for multicasting data in a communication network |
| US7898957B2 (en) * | 2005-10-03 | 2011-03-01 | The Hong Kong University Of Science And Technology | Non-blocking destination-based routing networks |
| US8107473B2 (en) | 2006-03-16 | 2012-01-31 | Cisco Technology, Inc. | Automation fallback to P2P LSPs for mLDP built multipoint-trees |
| US7852841B2 (en) * | 2005-11-04 | 2010-12-14 | Cisco Technology, Inc. | In-band multicast signaling using LDP |
| CN1852247A (zh) * | 2005-11-25 | 2006-10-25 | 华为技术有限公司 | 一种解决IGMP Leave报文丢失引起的组播业务异常的方法 |
| US8068490B1 (en) * | 2006-02-27 | 2011-11-29 | Cisco Technology, Inc. | Methods and systems for multicast group address translation |
| US7742475B2 (en) * | 2006-05-03 | 2010-06-22 | Cisco Technology, Inc. | Techniques for distributing replication points for traffic using point-to-point links |
| FI20065479A0 (fi) * | 2006-07-05 | 2006-07-05 | Nokia Corp | Ryhmäkommunikaatio |
| US20080186962A1 (en) * | 2007-02-01 | 2008-08-07 | Cisco Technology, Inc. | Policy-Based Tunneling of Multicast Streams |
| US20080285496A1 (en) * | 2007-05-14 | 2008-11-20 | Bamboo Mediacasting Ltd. | Data download in wireless network |
| EP2046041A1 (en) * | 2007-10-02 | 2009-04-08 | Alcatel Lucent | Multicast router, distribution system,network and method of a content distribution |
| TWI452878B (zh) * | 2008-03-21 | 2014-09-11 | Ralink Technology Corp | 封包處理系統及方法 |
| US20090252163A1 (en) * | 2008-04-03 | 2009-10-08 | Telcordia Technologies, Inc. | Grammar and Ontology for Multicast Communication |
| WO2010097792A2 (en) * | 2009-02-24 | 2010-09-02 | Airmeup Ltd. | Method and system of mobile device communication |
| CN102158911A (zh) * | 2010-02-11 | 2011-08-17 | 华为技术有限公司 | 机器对机器业务的承载建立方法及网络传输设备 |
| KR20120041902A (ko) * | 2010-10-22 | 2012-05-03 | 삼성전자주식회사 | 광대역 무선통신 시스템에서 멀티캐스트 데이터를 전송하기 위한 방법 및 장치 |
| CN103430483B (zh) * | 2011-03-03 | 2016-07-27 | 瑞典爱立信有限公司 | 用于确定通信系统中的关联事件的技术 |
| EP2730060A4 (en) * | 2011-07-06 | 2014-12-03 | Ericsson Telefon Ab L M | DYNAMIC UPDATE OF A LABEL SWITCHED PATH |
| US8842651B2 (en) | 2012-11-28 | 2014-09-23 | Motorola Solutions, Inc. | Access point groupings bridging tunneled traffic for a communication network |
| US10349225B2 (en) * | 2013-08-27 | 2019-07-09 | Verizon Patent And Licensing Inc. | Private multicast networks |
| FR3011424A1 (fr) * | 2013-09-30 | 2015-04-03 | Orange | Procedes de configuration et de gestion d'un reseau ip, dispositifs et programmes d'ordinateur correspondants. |
| US9794855B2 (en) | 2014-10-01 | 2017-10-17 | At&T Intellectual Property I, L.P. | Facilitation of geographically addressed data streaming |
| US10085296B1 (en) * | 2016-06-16 | 2018-09-25 | Sprint Spectrum L.P. | Pre-establishment and use of access network connections to help expedite attachment |
| US11166326B2 (en) * | 2020-01-21 | 2021-11-02 | Juniper Networks, Inc. | Utilizing a transport protocol for fifth generation (5G) client devices to carry messages on wireline access |
| US11736349B2 (en) * | 2020-08-19 | 2023-08-22 | Verizon Patent And Licensing Inc. | Systems and methods for providing firmware over-the-air delivery to internet of things user equipment |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI105137B (fi) * | 1996-12-02 | 2000-06-15 | Nokia Networks Oy | Parannettu ryhmälähetys pakettiverkossa |
| US6331983B1 (en) * | 1997-05-06 | 2001-12-18 | Enterasys Networks, Inc. | Multicast switching |
| US6608832B2 (en) * | 1997-09-25 | 2003-08-19 | Telefonaktiebolaget Lm Ericsson | Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services |
| FI108192B (fi) * | 1998-03-19 | 2001-11-30 | Nokia Networks Oy | Menetelmä ja laitteisto palvelun laadun kontrolloimiseksi matkaviestinjärjestelmässä |
| EP1163758B1 (en) * | 1999-03-19 | 2003-09-10 | Nokia Corporation | Method and network element for forwarding multicast messages |
| EP1071296A1 (en) * | 1999-07-22 | 2001-01-24 | Alcatel | Method to multi-cast data packets to mobile stations, and related gateway, service and routing nodes |
| US7068680B1 (en) * | 1999-10-01 | 2006-06-27 | Accenture Llp | Communication service architectures for netcentric computing systems |
| US7023820B2 (en) * | 2000-12-28 | 2006-04-04 | Nokia, Inc. | Method and apparatus for communicating data in a GPRS network based on a plurality of traffic classes |
| FI20001574A (fi) * | 2000-06-30 | 2001-12-31 | Nokia Corp | Resurssien allokointi ja palvelun välittäminen langattoman verkon yli |
| US6996414B2 (en) * | 2001-04-30 | 2006-02-07 | Motorola, Inc. | System and method of group calling in mobile communications |
-
2002
- 2002-06-20 DE DE60205748T patent/DE60205748T2/de not_active Expired - Lifetime
- 2002-06-20 AU AU2002351954A patent/AU2002351954A1/en not_active Abandoned
- 2002-06-20 EP EP02780905A patent/EP1400057B1/en not_active Expired - Lifetime
- 2002-06-20 JP JP2003509703A patent/JP3942033B2/ja not_active Expired - Lifetime
- 2002-06-20 US US10/481,078 patent/US8098618B2/en not_active Expired - Fee Related
- 2002-06-20 AT AT02780905T patent/ATE303025T1/de not_active IP Right Cessation
- 2002-06-20 WO PCT/EP2002/006827 patent/WO2003003650A2/en active IP Right Grant
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011125029A (ja) * | 2003-03-12 | 2011-06-23 | Orange Sa | 電気通信 |
| JP2011510590A (ja) * | 2008-01-25 | 2011-03-31 | エスイーエイエイチ ネットワークス カンパニー リミテッド | ＷｉＭＡＸにおけるマルチキャストブロードキャストサービス（ＭＢＳ）支援方法及び装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| ATE303025T1 (de) | 2005-09-15 |
| WO2003003650A3 (en) | 2003-05-01 |
| EP1400057A2 (en) | 2004-03-24 |
| US20040233907A1 (en) | 2004-11-25 |
| DE60205748T2 (de) | 2006-06-08 |
| US8098618B2 (en) | 2012-01-17 |
| AU2002351954A1 (en) | 2003-03-03 |
| EP1400057B1 (en) | 2005-08-24 |
| WO2003003650A2 (en) | 2003-01-09 |
| JP3942033B2 (ja) | 2007-07-11 |
| DE60205748D1 (de) | 2005-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3942033B2 (ja) | ポイントツーポイントパケット交換向きのネットワークにおけるマルチキャスト方法 | |
| US7369541B2 (en) | Multicast in a point-to point oriented packet-switched telecommunication network | |
| US7606186B2 (en) | Multicast in point-to-point packet-switched oriented networks | |
| US7680109B2 (en) | Mobile multipoint service | |
| US7107066B2 (en) | Multicast support in packet switched wireless networks | |
| US7499466B2 (en) | Multicast group management in telecommunication networks | |
| US7957376B2 (en) | Efficient MBMS backbone distribution using one tunnel approach | |
| CN100420192C (zh) | 在通用移动电信系统网络中进行组播的方法和装置 | |
| EP1454454B1 (en) | Method and device for broadcast in point-to-point packet networks | |
| WO2007059679A1 (fr) | Procede pour le traitement de service multidiffusion anormal et equipement de reseau associe | |
| WO2008072691A1 (ja) | 通信方法および無線通信システム | |
| WO2008154796A1 (fr) | Procédé et équipement permettant de commander la transmission de paquets de données de multidiffusion dans la station de base et la passerelle du système wimax | |
| Efstathiou et al. | Mobile Multicast |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050525 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050525 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070302 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070329 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3942033 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110413 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120413 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120413 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140413 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |