(57)【要約】【課題】ユニキャストプロトコルを使用したマルチキャスト送信を行うことを目的とする。【解決手段】ユニキャストプロトコルを使用したサーバ（4）と複数のクライアント（6、8）のうち少なくとも１つとの間のマルチキャスト送信のための方法であり、この方法は、サーバ（4）とクライアント（6、8）との間のマルチキャストパス（16）及びユニキャストパス（10、12）の共同した動作を可能にするために、クライアント（6、8）に対してマルチキャストパス（16）でサーバ（4）と通信することを可能にする情報をサーバ（4）によりクライアント（6、8）に提供するステップを有する。【選択図】図１
2014023150.tif 000002
【特許請求の範囲】
【請求項１】
ユニキャストプロトコルを使用したサーバと複数のクライアントのうち少なくとも１つとの間のマルチキャスト送信のための方法であって、
前記サーバと前記クライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、前記クライアントに対してマルチキャストパスで前記サーバと通信することを可能にする情報を前記サーバにより前記クライアントに提供するステップを有する方法。
【請求項２】
前記ユニキャストプロトコルはマルチホーミングプロトコルである、請求項１に記載の方法。
【請求項３】
前記マルチホーミングプロトコルは、ストリーム制御伝送プロトコル（SCTP）又はSCTPの拡張である、請求項２に記載の方法。
【請求項４】
前記クライアントに対して前記マルチキャストパスで前記サーバと通信することを可能にする前記情報は、SCTPアソシエーションを初期化することを可能にする初期化情報を有する、請求項３に記載の方法。
【請求項５】
前記初期化情報は、定期的に前記マルチキャストパスでブロードキャストされる初期化チャンクで伝達される、請求項４に記載の方法。
【請求項６】
前記初期化チャンクは、前記SCTPアソシエーションにより伝達されるアウトバウンドストリームの数をアドバタイズするフィールドを有する、請求項５に記載の方法。
【請求項７】
前記初期化チャンクは、前記サーバによりサポートされる少なくとも１つのIPアドレスを有する、請求項５又は６に記載の方法。
【請求項８】
前記初期化情報は、前記クライアントに利用可能にされたファイルに記述される、請求項４に記載の方法。
【請求項９】
前記クライアントにより実行されるSCTPアソシエーションの初期化ステップを有する、請求項４ないし８のうちいずれか１項に記載の方法。
【請求項１０】
ユニキャストプロトコルを使用して複数のクライアントのうち少なくとも１つと通信可能なサーバであって、
前記サーバとクライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、クライアントに対してマルチキャストパスで前記サーバと通信することを可能にする情報を前記クライアントに提供する管理モジュールを有するサーバ。
【請求項１１】
前記ユニキャストプロトコルは、ストリーム制御伝送プロトコル（SCTP）又はSCTPの拡張であり、
前記クライアントに対して前記マルチキャストパスで前記サーバと通信することを可能にする前記情報は、SCTPアソシエーションを初期化することを可能にする初期化情報を有する、請求項１０に記載のサーバ。
【請求項１２】
ユニキャストプロトコルを使用してサーバと通信可能なクライアントであって、
前記サーバと前記クライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、前記クライアントに対してマルチキャストパスで前記サーバと通信することを可能にする情報を受信する受信モジュールを有するクライアント。
【請求項１３】
前記ユニキャストプロトコルは、ストリーム制御伝送プロトコル（SCTP）又はSCTPの拡張であり、
前記クライアントに対して前記マルチキャストパスで前記サーバと通信することを可能にする前記情報は、SCTPアソシエーションを初期化することを可能にする初期化情報を有する、請求項１２に記載のクライアント。
【請求項１４】
コンピュータに対して請求項１ないし９のうちいずれか１項に記載の方法のステップを実行可能にするコンピュータ実行可能命令を有するコンピュータ可読プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してネットワーク内で情報を伝送するために使用されるトランスポートレイヤプロトコルの分野に関する。
【０００２】
特に、本発明は、IETF（Internet  Engineering  Task  Force）によりIETF  RFC  4906で標準化されたSCTP（Stream  Control  Transport  Protocol）として知られるストリーム制御トランスポートプロトコルを扱う。従って、本発明は、ユニキャストプロトコルを使用したマルチキャスト送信のための方法、クライアント及びサーバに関する。また、本発明の方法を実施するコンピュータプログラムにも関する。
【背景技術】
【０００３】
この部分に記載の手法は追求され得るものであるが、必ずしも前に検討又は追求された手法であるとは限らない。従って、特にここに示さない限り、この部分に記載の手法は、この出願の特許請求の範囲に対する従来技術ではなく、この部分に含めることにより従来技術であると認定されるべきではない。
【０００４】
ストリーム制御伝送プロトコル（SCTP：Stream  Control  Transmission  Protocol）は、現代のインターネットプロトコル（IP：Internet  Protocol）ネットワークの拡張機能を使用し、更なるアプリケーション要件をサポートするための、伝送制御プロトコル（TCP：Transmission  Control  Protocol）に一式の高度な機能を追加したようなサービスを提供する汎用のトランスポートレイヤプロトコルである。現在では、全ての主なオペレーティングシステムにSCTPの実装が存在する。
【０００５】
IETFにより指定されたSCTPプロトコルは、セルラコアネットワーク内でシグナリング情報を伝送するために3GPP（3rd  Generation  Partnership  Project）で使用されている。SCTPは、IP上での電話のシグナリングの伝送のために、TCPに固有の特定の制限に対処するために設計されたものである。SCTPの主な設計目標の１つは、シグナリングメッセージを伝送するために重要な、ネットワークの耐故障性のある方法での小さいメッセージの効率的な伝送であった。従って、SCTPは、アプリケーションユーザへのサービスメッセージの伝送のための信頼性の高いデータ伝送サービスを提供する。
【０００６】
SCTPは、メッセージ境界（message  boundary）を保持するコネクション指向型の汎用のトランスポートプロトコルである。SCTPアソシエーションと呼ばれるSCTP接続は、IPv4及びIPv6の上で使用可能である。
【０００７】
メッセージは、チャンク（chunk）と呼ばれるデータ構造にカプセル化される。チャンク自体は、SCTPパケットにカプセル化される。更に、SCTPは、TCPで利用可能ではない新たな機能を組み込んでいる。
【０００８】
従来のトランスポートレイヤプロトコルでSCTPにより提供される最も重要な拡張の１つは、マルチホーミング（multihoming）である。このマルチホーミング機能は、SCTPアソシエーションが複数の送信元及び宛先アドレスを使用することを可能にする。そして、各ノードは、アソシエーションの確立のときに複数のアドレスセットによりアクセスされ得る。トランスポートのアドレスは、SCTPアソシエーションの初期化中に交換される。
【０００９】
マルチホーミング機能は、今日まで信頼性を提供する方法として使用されている。送信元と宛先との間のパスが故障すると常に、トラヒックがセカンダリパスの１つで流れ続けることができるため、SCTPアソシエーションが留まる。
【００１０】
近年、全体の帯域幅が増加するように、SCTPにより許可された異なる利用可能な接続パスを同時に使用し、本質的にモビリティ管理を拡張することが提案されている。
【００１１】
前述のデフォルトのTCPのような動作の他に、SCTPはまた、RFC  3753で指定されたSCTP-PR（SCTP-Partial  reliability）という名の拡張において、ユーザデータグラムプロトコル（UDP：User  Datagram  Protocol）のような非送達確認のトラヒックもサポートする。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
F.  Yong,  W.  Chee及びS.RamadassによるNational  Computer  Science  Postgraduate  Colloquium  (NaCSPC),  2005の“M-SCTP:  transport  layer  multicasting  protocol”という題名の文献では、マルチキャストSCTP（M-SCTP：Multicast  SCTP）を利用した方式が記載されている。この方式は、SCTPサーバとそのSCTPクライアントとの間にM-SCTPサーバスタックを追加する。サーバスタックは、マルチキャストサービスのリソースを管理し、マルチキャストメンバシップを制御する。しかし、この方式は、繰り返しのユニキャストプロトコルのメッセージ送信を使用することにより、マルチキャスト機能を実現している。言い換えると、マルチキャストは、データパケットを複製し、複数のユニキャストプロトコルのメッセージ送信を個々に使用してこれらを各クライアントに送信することにより、サーバスタックにより実現されている。従って、この方式は、低い帯域幅の効率又は劣ったシステムスケーラビリティから生じる問題を解決しない。
【００１３】
文献WO2011/071474は、SCTPへのマルチキャストのサポートの追加を可能にする方式の利点を引き出している。
【００１４】
この概念は、マルチキャスト環境でSCTPトランスポートプロトコルを動作させることであるが、前の段落で説明したように、SCTPは、主にTCP/UDPのような接続のために設計されている。
【００１５】
特にビデオ配信を検討すると、マルチキャスト及び／又はブロードキャストから利益を受けることに関心がある複数の場合が存在する。しかし、ロバスト性、サービスの接続性等のために、ブロードキャスト媒体に双方向媒体を関連付けることが一般的である。今日では、ユニキャスト又はマルチキャストのような異なる媒体及びこれらの特性に対処することは、アプリケーション次第である。
【００１６】
UCP上でのマルチキャストのみを含む従来技術は、例えば共有通信リンクで複数の宛先にストリームを配信するストリーミングサーバとしての送信元の場合に対処するが、このようなマルチキャストコンテンツの配信を実現するために複数のリンクの同時の使用は可能にしない。
【００１７】
前述の引用文献WO2011/071474は、このようなマルチキャスト送信を実現するためのSCTPプロトコルへの変更を提供しない。
【００１８】
本発明は、この状況を改善する対策を提案する。
【課題を解決するための手段】
【００１９】
従って、本発明は、ユニキャストプロトコルを使用したサーバと複数のクライアントのうち少なくとも１つとの間のマルチキャスト送信のための方法を提供し、この方法は、サーバとクライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、クライアントに対してマルチキャストパスでサーバと通信することを可能にする情報をサーバによりクライアントに提供するステップを有する。
【００２０】
クライアントに対してマルチキャストパスでサーバと通信することを可能にする情報をサーバからクライアントに提供することにより、本発明の方法は、ユニキャストパス及びマルチキャストパスの双方を共同して又は択一的に使用することを可能にする。
【００２１】
有利には、ユニキャストプロトコルはマルチホーミングプロトコルである。
【００２２】
好ましくは、マルチホーミングプロトコルは、ストリーム制御伝送プロトコル（SCTP：Stream  Control  Transmission  Protocol）又はSCTPの拡張である。
【００２３】
このような拡張の例は、SCTP-PRである。
【００２４】
有利には、SCTPの場合、クライアントに対してマルチキャストパスでサーバと通信することを可能にする情報は、SCTPアソシエーションを初期化することを可能にする初期化情報を有する。
【００２５】
本発明では、IPユニキャストベアラに関連する同時のIPマルチキャストベアラが使用されるマルチキャストSCTPサービスを設計することが可能である。
【００２６】
第１の実施例によれば、初期化情報は、定期的にマルチキャストパスでブロードキャストされる初期化チャンクで伝達される。
【００２７】
有利には、初期化チャンクは、SCTPアソシエーションにより伝達されるアウトバウンドストリームの数をアドバタイズするフィールドを有する。
【００２８】
有利には、初期化チャンクは、サーバによりサポートされる少なくとも１つのIPアドレスを有する。
【００２９】
特に、ブロードキャストされる初期化チャンクは、サーバに連絡し得る一式のIPv4/IPv6アドレスを有する。これらのアドレスは、他の可能なマルチキャストベアラを含んでもよい。
【００３０】
第２の実施例によれば、初期化情報は、クライアントに利用可能にされたファイルに記述される。
【００３１】
例えば、このようなファイルは、いずれかの可能な手段で（例えば、サービス案内の一部として）クライアントに利用可能にされたSDPファイルでもよく、ネットワークオペレータにより予めロードされてもよい。
【００３２】
有利には、この方法は、クライアントにより実行されるSCTPアソシエーションの初期化ステップを有する。
【００３３】
これは、クライアントとサーバとの間の上りリンクパスが利用可能である場合に可能である。
【００３４】
本発明は、ユニキャストプロトコルを使用して複数のクライアントのうち少なくとも１つと通信可能なサーバを更に提供する。このサーバは、サーバとクライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、クライアントに対してマルチキャストパスでサーバと通信することを可能にする情報をクライアントに提供する管理モジュールを有する。
【００３５】
本発明はまた、ユニキャストプロトコルを使用してサーバと通信可能なクライアントを提供する。このクライアントは、サーバとクライアントとの間のマルチキャストパス及びユニキャストパスの共同した動作を可能にするために、クライアントに対してマルチキャストパスでサーバと通信することを可能にする情報を受信する受信モジュールを有する。
【００３６】
本発明によるマルチキャスト送信のための方法は、プログラム可能装置のソフトウェアに実装されてもよい。これは、単にハードウェアに実装されてもよく、ソフトウェアに実装されてもよく、これらの組み合わせに実装されてもよい。
【００３７】
本発明はソフトウェアに実装可能であるため、本発明は、いずれかの適切な搬送媒体でプログラム可能装置に提供するコンピュータ可読コードとして具現されてもよい。搬送媒体は、フロッピーディスク、CD-ROM、ハードディスクドライブ、磁気テープデバイス又は固体メモリデバイス等を有してもよい。
【００３８】
従って、本発明は、コンピュータが本発明の方法のステップを実行することを可能にするコンピュータ実行可能命令を有するコンピュータ可読プログラムを提供する。図３の図面は、このようなコンピュータプログラムの一般的なアルゴリズムの例を示している。
【図面の簡単な説明】
【００３９】
【図１】SCTPを使用して本発明の実施例によるマルチキャスト送信方法を実装する伝送システムの実施例の概略図
【図２】本発明の実施例による初期化チャンクの例
【図３】本発明の実施例によるマルチキャスト送信方法のステップを示すフローチャート
【発明を実施するための形態】
【００４０】
図１を参照すると、本発明の実施例によるマルチホーミングユニキャストプロトコル（特にSCTP）を使用した伝送システム2の概略図が示されている。
【００４１】
伝送システム2は、SCTP管理モジュール5を含むサーバ4と、それぞれ受信モジュール7、9を含む第１のクライアント6及び第２のクライアント8とを有する。図１は、２つのクライアントを示しているが、システム2は、２つのクライアントを用いた動作に限定されず、１〜複数のクライアントをサポートしてもよい。
【００４２】
サーバ4は、クライアント6、8に配信されるコンテンツを有する記憶媒体を含む。有利には、サーバ4は、クライアントデバイス特性（例えば、再生機能、画面解像度、及びクライアント6、8がマルチキャスト接続に加えてユニキャスト接続を確立しているか否か等）をトラッキングすることを可能にするクライアント状態又はプロフィール情報を維持管理する。従って、この状態情報は、例えば異なるサウンドトラック又は拡張した品質のように、クライアントのいくつかのためのターゲティングされたコンテンツを選択的に追加するために使用されてもよい。
【００４３】
それぞれ個々のクライアント6、8は、サーバ4とデータパケットを交換するために使用される複数のIPアドレスを含んでもよい。個々のクライアントのIPアドレスは、サーバ4のIPアドレスとの通信パスを生成し、個々のクライアント6、8とサーバ４との間でデータパケットの交換を容易にするために使用される。サーバ4はまた、複数のアクセスネットワークを通じて個々のクライアント6、8との通信パスを形成してもよい。
【００４４】
例えば、図１に示すように、サーバ4は、それぞれユニキャストアクセスパス10、12を通じてクライアント6、8と通信してもよい。ユニキャストアクセスパス10、12は、例えば、3GPP（3rd  Generation  Partnership  Project）ユニキャストネットワークに対応する。
【００４５】
本発明によれば、サーバ4は、マルチキャストアクセスパス14、16を通じてクライアント6、8と通信してもよい。マルチキャストアクセスパス14、16は、例えば、それぞれ3GPP  MBMS（Multimedia  Broadcast  and  Multicast  Services）ネットワーク及びDVB-H（Digital  Video  Broadcasting-Handheld）に対応する。
【００４６】
サーバ4に存在するSCTPプロトコルスタック18は、サーバ4とクライアント6、8との間のマルチキャストアソシエーションを扱い、クライアントがユニキャストアドレスをアソシエーションに追加すると常に新たなクライアントを登録する。これは、マルチキャスト接続でデータチャンクをクライアント6、8に送信し、クライアント6、8により明示的に要求された場合にデータを再送信するため又はデータを選択的に配信するために、個々のクライアント6、8へのユニキャスト接続を使用する。
【００４７】
図１は、３つのアクセスネットワークを示しているが、システムは、３つのアクセスネットワークを用いた動作に限定されず、ユニキャスト又はマルチキャスト送信をサポートする１〜複数のアクセスネットワークとサーバ4との間の接続パスをサポートしてもよい。
【００４８】
ユニキャストパス10、12は、サーバ4と各クライアント6、8との間の双方向の上りリンク及び下りリンクでのユニキャスト通信サポート機能を提供する。
【００４９】
マルチキャストパス14、16は、一方向の下りリンクのみをサポートする。その結果、各クライアント6、8からサーバ4へのフィードバックチャネルは、マルチキャストパス14、16を通じて利用可能ではない。
【００５０】
クライアント6、8はまた、複数のネットワークインタフェースを有し、異なる種類の通信ネットワークを介して遠隔システムに接続可能でもよい。特に、クライアント6、8は、前述のアクセスネットワークの３つの全てを通じて遠隔システムに接続してもよく、従って、ユニキャスト双方向リンク及びマルチキャスト一方向リンクの双方を有してもよい。
【００５１】
各クライアント6、8は、例えば、データファイルを処理し、アプリケーションを実行し、データの送信、受信及び処理についての命令のためにサーバと通信することが可能なコンピュータ又はモバイルデバイスでもよい。
【００５２】
クライアント6、8は、特定の機能を実行可能にするために、サーバ4からコンテンツを要求してもよい。例えば、クライアント6、8は、ユーザのデータを適切に処理して表示するために、サーバ4から特定のデータを受信しなければならないオーディオ／ビデオデバイスでもよい。従って、データの送信を容易にするために、クライアント6、8とサーバ4との間のアソシエーションが必要になる。
【００５３】
本発明によれば、ハイブリッドのマルチキャスト／ユニキャスト送信は、SCTPレイヤ（すなわち、SCTPプロトコルスタック18）により扱われる。
【００５４】
例えば、少し拡張されたソケットのアプリケーションプログラミングインタフェース（API：Application  Programming  Interface）で構成されたインタフェース20、22、24は、アソシエーションパラメータを読み取って変更するために、それぞれサーバ4、クライアント6及びクライアント8の側で使用される。拡張ソケットAPI20、22、24は、ユニキャスト接続を確立したクライアントのリストの読み取りを可能にする。
【００５５】
サーバ4とクライアント6、8との間のアソシエーションは、マルチリンク側を通じてサーバ4により開始されてもよく、上りリンクパス10、12を通じてクライアント6、8により開始されてもよい。
【００５６】
SCTPアソシエーションは、従来の４方向ハンドシェイク（four  ways  handshake）を通じて開始される。当然に、この接続設定は、上りリンクパス（パス10、12）が利用可能な場合にのみ、クライアントにより使用されてもよい。
【００５７】
本発明の第１の実施例によれば、このアソシエーションは、RFC  4960に規定されたINITチャンクとは異なるBINITチャンクと呼ばれる初期化チャンクを使用する。このチャンクは、定期的にマルチキャストパス14、16でブロードキャストされ、SCTPアソシエーションにより伝達されるアウトバウンドストリームの数をアドバタイズする。
【００５８】
本発明の初期化チャンクBINIT30の例を図２に示す。
【００５９】
BINITチャンクは、SCTPアソシエーションのINITチャンクの以下の従来のフィールドを有する。
【００６０】
・ソースポート番号32：このフィールドは、SCTP送信機のポート番号を識別する。これは、パケットが属するアソシエーションを識別するために、送信元IPアドレス、SCTP宛先ポート及び場合によっては宛先IPアドレスと組み合わせて、受信機により使用されてもよい。
【００６１】
・宛先ポート番号34：このフィールドは、検討されるパケットが向かうSCTPポート番号を識別する。受信ホストは、SCTPパケットを正確な受信エンドポイント／アプリケーションに逆多重するためにこのポート番号を使用する。
【００６２】
・確認タグ36：このフィールドは、検討されるSCTPパケットの送信機を確認するために使用される。双方向（すなわち、従来のSCTPアソシエーション）の場合、この確認タグの値は、アソシエーション初期化中に相手のエンドポイントから受信した開始タグの値に設定される。本発明の好ましい実施例によれば、アソシエーションは、マルチキャストの宛先ではクライアントとのハンドシェイクなしにサーバ4から開始され得るため、この確認タグは、マルチキャストアソシエーションの開始時にランダムに選択された値に設定される。
【００６３】
・チェックサム38：このフィールドは、検討されるSCTPパケットのチェックサムを含む。
【００６４】
・チャンクタイプ40：このフィールドは、チャンクデータに含まれる情報の種別を識別する。
【００６５】
・チャンクフラグ42：このフィールドの使用は、チャンクタイプに依存する。
【００６６】
・チャンク長44：このフィールドは、チャンクのサイズをバイトで示す。
【００６７】
・開始タグ46：このフィールドの値は、INITチャンクの確認タグの内容を設定するために、双方向接続を開始しようとするクライアントにより使用される。
【００６８】
・初期TSN48：このフィールドは、使用される初期の送信シーケンス番号を示す。
【００６９】
・予備50：このフィールドは、将来の使用のために確保される。
【００７０】
・任意選択／可変長パラメータ52：このフィールドは、任意選択のパラメータを含む。
【００７１】
その他に、本発明の第１の実施例によれば、BINITチャンクは、新たなフィールド54を含む。新たなフィールド54は、アソシエーションにより伝達されるアウトバウンドストリームの数を含み、INITチャンクにある数又はアウトバウンドストリームフィールドと同じように符号化される。この情報は、通常ではアソシエーションが確立されるともはやアドバタイズされないため、この値は、アソシエーションに参加するクライアントが、どのくらいの数のストリームがアソシエーションの一部になっているかを認識することを可能にする。
【００７２】
図３のフローチャートは、第１の実施例による本発明の方法のステップの詳細を示している。
【００７３】
ステップ60において、サーバ4は、マルチキャストパス16で定期的にBINITチャンク30をブロードキャストする。
【００７４】
ここではユニキャストパス10、12のような上りリンクの場合に、クライアント6、8はBINITチャンクを待機し、ステップ62において、次の４方向ハンドシェイクを開始するINITチャンクの確認タグ値として開始タグ値を使用する。入来するINITチャンクを処理するサーバ4は、クライアントが新たな“従来の”SCTPアソシエーションを設定することを試みていないことを示すヌルでない確認タグを検出する。その代わりに、受信した確認タグ値は、サーバ4が、クライアントが双方向パスを使用して参加しようとするマルチキャストSCTPアソシエーションを識別することを可能にする。クライアントとの残りの４方向ハンドシェイクを処理した後に、サーバのSCTPプロトコルスタック18は、クライアントのIPアドレスを既存のマルチキャストアソシエーションに統合している。
【００７５】
ステップ64において、サーバ10は、任意選択のフィールド52を通じて、サポートする一式のIPv4/IPv6アドレスと、マルチキャストパス14、16で使用されるマルチキャストアドレスのリストとを、そのBINITチャンク及び可能な次のINIT  ACKチャンクで示す。アドレスは、RFC  4960によりINITチャンクに関して符号化される。
【００７６】
本発明の第２の実施例によれば、アソシエーションの特性は、SDPファイルに記述される。このファイルは、いずれかの可能な手段で（例えば、サービス案内の一部として又はネットワークオペレータによる予めのロードとして）クライアント6、8に利用可能にされる。
【００７７】
クライアント6、8が上りリンク接続を開始しようとする場合、異なる機構が使用される。実際に、サーバは、マルチキャストリンクで送信される全てのチャンクの確認タグを、サーバによるアソシエーションの開始時に選択された固定値に設定する。クライアント6、8は、マルチキャストリンク16で受信したチャンクにある確認タグの値に設定された確認タグでINITチャンクを送信する。これは、クライアント6、8が新たなアソシエーションを開始するのではなく、このユニキャストチャンクを既存のアソシエーションに追加しようとしていることを示す。開始タグは、通常のSCTPハンドシェイクでのように、クライアント6、8により選択された値に設定される。サーバ4は、クライアント6、8により提供された開始タグの値に設定された確認タグを用いて、INIT  ACKチャンクで応答する。
【００７８】
サーバ4の観点から、アプリケーションは、１対複数のSCTPソケットをオープンする。しかし、ソケットを生成するときに、従来のSOCK_SEQPACKETの代わりにSOCK_DGRAM種別が使用される。これは、基礎となる接続の事実上の接続しない性質を示す。これはまた、潜在的なポイント・ツー・ポイントのアソシエーションが設定され得ることをSCTPプロトコルスタック18に示す。
【００７９】
サーバ4のアプリケーションは、データを送信するために通常のソケットAPIを使用する。
【００８０】
BINITチャンクを生成し、マルチキャストパス14、16でトラヒックを配信し始めるのは、TCPプロトコルスタック18次第である。
【００８１】
クライアント6、8の観点から、アプリケーションは、SOCK_DGRAM種別と同様に、１対複数のSCTPソケットを生成する。クライアント6、8のプログラミングモデルは、従来のマルチキャスト受信機のようになる。IGMPを扱うためにIP_ADD_MEMBERSHIPオプションでソケットAPIからの標準的なsetsockopt関数を呼び出す。次に、クライアント6、8は、ソケットを特定のマルチキャスト可能なインタフェースに結びつけ、入来するパケットを待機する。
【００８２】
対応するマルチキャストトラヒックを受信し、可能である場合には送信元SCTPエンドポイントとの新たなユニキャストアソシエーションを生成することは、SCTPプロトコルスタック18次第である。
【００８３】
クライアント6、8の観点から、トラヒックは、通常のソケットと同様にSCTPソケットから読み取られる。更なる上りリンクを有することは、クライアント6、8にとってトランスペアレント（transparently）に失ったパケットの再送信を要求する可能性をSCTPソケットに与える。
【００８４】
図１の特定のユースケースでは、例えばDVB-H及びMBMSのように１つより多くのマルチキャスト配信機構が存在する場合、ソケットAPIを通じて事後に（posteriori）マルチキャストパスを追加することが可能である。
【００８５】
特に、本発明は、ダウンストリームのマルチキャスト配信と、任意選択の双方向ユニキャストリンクとをトランスポートレイヤで統合する。マルチキャストUDPを利用する従来のアプリケーションは、ほとんど変更なしに再利用可能である。多数のクライアントは、配信ネットワークを溢れさせることなく、マルチキャストストリームを受信することが可能になる。この理由は、マルチキャストがネットワークによりサポートされる場合、データの複製が回避されるからである。更なる帯域幅によるユーザ経験を向上させるため又はネットワークカバレッジの理由でマルチキャストが利用可能でない地域でサービスの継続性を保証するために使用され得る更なる双方向のユニキャストリンクは、アプリケーションにとってトランスペアレントにクライアントにより確立されてもよい。
【００８６】
現時点で本発明の好ましい実施例と考えられるものについて図示及び説明したが、本発明の真の範囲を逸脱することなく、様々な他の変更が行われてもよく、等価なものが置換されてもよことが、当業者に分かる。更に、ここに記載の本発明の中心的な概念を逸脱することなく、特定の状況を本発明の教示に適合させるために、多くの変更が行われてもよい。更に、本発明の実施例は、前述の特徴の全てを含まなくてもよい。従って、本発明は、開示された特定の実施例に限定されず、本発明は特許請求の範囲内に入る全ての実施例を含むことを意図する。
【００８７】
“有する”、“含む”、“組み込む”、“包含する”、“である”及び“持つ”のような表現は、説明及びその関連する請求項を解釈するときに非限定的に解釈されるべきではない。すなわち、明示的に定義されていない他の項目又は構成要素も存在することを許容するように解釈されるべきである。単数への言及は、複数への言及としても解釈されるべきであり、その逆も同様である。
【００８８】
この説明に開示された様々なパラメータが変更されてもよく、開示された様々な実施例及び／又は特許請求の範囲に記載された様々な実施例は、本発明の範囲を逸脱することなく組み合わされてもよいことが、当業者は容易に分かる。
【符号の説明】
【００８９】
2  伝送システム
4  サーバ
5  SCTP管理モジュール
6  クライアント
7  受信モジュール
8  クライアント
9  受信モジュール
10  ユニキャストアクセスパス
12  ユニキャストアクセスパス
14  マルチキャストアクセスパス
16  マルチキャストアクセスパス
18  SCTPプロトコルスタック
20  インタフェース
22  インタフェース
24  インタフェース
【図１】
2014023150.tif 000003
【図２】
2014023150.tif 000004
【図３】
2014023150.tif 000005
【外国語明細書】
2014023150000001.pdf