JP5873124B2 - 負荷分散信号分配を行う方法および装置 - Google Patents
負荷分散信号分配を行う方法および装置 Download PDFInfo
- Publication number
- JP5873124B2 JP5873124B2 JP2014051879A JP2014051879A JP5873124B2 JP 5873124 B2 JP5873124 B2 JP 5873124B2 JP 2014051879 A JP2014051879 A JP 2014051879A JP 2014051879 A JP2014051879 A JP 2014051879A JP 5873124 B2 JP5873124 B2 JP 5873124B2
- Authority
- JP
- Japan
- Prior art keywords
- gateway
- streamer
- proxy server
- request
- video
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
- H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44227—Monitoring of local network, e.g. connection or bandwidth variations; Detecting new devices in the local network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Computer And Data Communications (AREA)
Description
本願は、2008年2月29日に米国特許商標庁に出願された米国仮特許出願第61/067585号に対する優先権を主張し、そこから生じる特典を請求するものである。
図1の負荷分散システムでは、例示として、ストリーマ・ゲートウェイ10を並列に配線して、全てのストリーマ・ゲートウェイ10が全てのネットワーク・フィードを受信するように示してある。この構成では、システムの再構成で、ストリーマ・ゲートウェイ10で障害が起きた後に物理的なケーブル布線の変更を行う必要がない。さらに、ストリーマ・ゲートウェイ10で障害が起きた場合に、システムは、障害の起きたストリーマ・ゲートウェイ10の現在のストリームを、その他のストリーマ・ゲートウェイ10に自動的に割り付けし直して、サービスの中断を最小限に抑えることができる。
1.従来のSTBクライアント・デバイスは、RTSPリダイレクトに対応していないことがある。
2.衛星ネットワーク・フィードは、複数のゲートウェイ間で共有しなければならない。例えば、複数のゲートウェイを並列に配線して、全てのゲートウェイ・シャーシ(gateway chassis)が全ての衛星ネットワークを受信するようにすることができる。
3.負荷分散は、構成ファイル・パラメータを使用してイネーブルすることができ、リブートの後に有効になる。
4.ストリーマ・ゲートウェイ・ネットワーク、チューナ、および偏波構成は、構成ファイル・パラメータとして設定しなければならない。さらに、ネットワークの自動検出/構成を追加することもできる。
5.トリプレット(triplet)(ネットワーク番号、トランスポンダ周波数、偏波設定)は、ストリーマ・ゲートウェイ間で一意的でなければならない。
6.補助(IXE0)インタフェースを、ゲートウェイ間通信に使用してもよい。
7.衛星ケーブル・フィードおよび/またはチューナ動作のトラブルシューティングおよび妥当性検査には、静的同調を使用しなければならない。静的同調の使用中には、システム動作が最適以下であってもよい。
・DHCP(動的ホスト構成プロトコル)サーバ、
・MTFTP(マルチキャスト・トリビアル・ファイル転送プロトコル)サーバ、
・プロキシ・モデム・サーバ、
・ICMP(インターネット制御メッセージプロトコル)「Ping」クライアント。
プロキシ・サーバ・ゲートウェイ20は、以下のサービスを提供するものとする。
・クライアントの状態の収集および監視を含む、プロキシRTSPサーバ。
・SNMPエージェントMIB(管理情報ベース)サポート。厳密には、DSFE(ディジタル・シグナリング・フロント・エンド)MIBがストリーマ・ゲートウェイ10と関連付けられ、プロキシ・サーバ・ゲートウェイ20の外部で扱われる。
・サービスが盗用されている可能性がないか検出するためのネットワーク・プロービング。
ストリーマ・ゲートウェイ10は、チューナ管理および映像データ・ポンプ機能を提供する。ストリーマ・ゲートウェイ10は、ネットワーク(図1参照)上のクライアント・デバイス(例えばSTB35)に対するRTSPサーバ・サポートを提供しないものとする。従って、ストリーマ・ゲートウェイ10は、RTSP特有の派生クラスを実施しないものとし、また必ずしもRID(受信者識別)やRIDリストなどを使用または考慮しないものとする。
・RTPセッションの制御および状態
・ハイレベル・チューナ状態
・例えばローカル・バスSAP(セッション・アナウンスメント・プロトコル)アナウンスメントを介した、ストリーマ・ネットワークの構成および状態
プロキシ・サーバ・ゲートウェイ20のRTSPソフトウェア・スタックは、以下のソフトウェア・モジュールを含む。
・プロキシRTSPサーバSAPリスナ・モジュール
プロキシ・サーバ・ゲートウェイ20は、ストリーマ・ゲートウェイ10のネットワークSAPアナウンスメントを監視するリスナ・モジュールを提供する。リスナは、239.255.255.255ポート19875など、特定のマルチキャスト・グループに加わるものとする。ストリーマ・ゲートウェイ10が最初のSAPアナウンスメントを受信すると、リスナ・モジュールは、新たなアプリケーション・タイマ(AppTimer)インスタンスを作成し、kRtspNewStreamerDetectedメッセージをプロキシ・サーバ・ゲートウェイ20に送信して、新たなストリーマ・ゲートウェイ10が検出されたことを示す。AppTimerのコールバック機能を使用して、ストリーマSAPアナウンスメントの失敗を検出する。このタイマは、次のストリーマSAPアナウンスメントを受信したときに、リロードされる。タイマが満期になった場合には、リスナ・モジュールは、kRtspStreamerFailedメッセージをプロキシ・サーバ・ゲートウェイ20に送信して、ストリーマ・ゲートウェイ10が失敗し、AppTimerインスタンスを削除しなければならないことを示す。リスナ・モジュールは、オンラインに戻った失敗したストリーマ・ゲートウェイ10を検出し、kRtspNewStreamerDetectedメッセージをプロキシ・サーバ・ゲートウェイ20に送信するものとする。
プロキシRTSPサーバ・モジュールは、シングル・スレッドである。プロキシRTSPサーバ・モジュールは、サービス・クライアントSTB35へのselect()コール、ならびに内部要求およびローカル・バス要求に依存している。例示的な実施例によれば、プロキシRTSPサーバ・モジュールは、SAPアナウンスメント・モジュールを実装し、クライアントRTSPプロトコル要求を処理し、プロキシ・サーバ・データベースを管理し、1つまたは複数のストリーマ・ゲートウェイ10との間でメッセージを送信および受信し、SAPアナウンスメント・モジュールからメッセージを受信して処理する。
kRtspNewStreamerDetectedメッセージを受信すると、プロキシ・サーバ・ゲートウェイ20は、新たなStreamerクラス/モジュール・インスタンスを作成し、適用可能なRtspStreamerMediaインスタンスにそのネットワークを追加するものとする。プロキシ・サーバ・ゲートウェイ20は、Streamerインスタンスに、アナウンスされたネットワークあたり1つのProxyRtspDsfeMediaインスタンスを追加する。
プロキシ・サーバ・ゲートウェイ20は、最新の集合体ネットワークSAPアナウンスメントを保持し、これを定期的に映像ネットワークにマルチキャストするものとする。アナウンスメントは、239.255.255.255ポート9875など、既定のマルチキャスト・グループに送信しなければならない。
ストリーマ・ゲートウェイ10の選択は、きめ細かく行うものとする。プロキシ・サーバ・ゲートウェイ20は、要求されたトリプレットと一致するアクティブなトリプレットがないか、全てのStreamerインスタンスを探索する。見つからない場合には、プロキシ・サーバ・ゲートウェイ20は、例えば下記のように計算される負荷率が最低であるストリーマ・ゲートウェイ10を認定して選択する。
ストリーマ・ゲートウェイ10の負荷率=現在の負荷/負荷設定点
ストリーマ選択:
既存のトリプレット一致を探す
for全てのストリーマの全てのProxyRtspDsfeMediaインスタンス for要求されたネットワークおよび偏波に一致する全てのメディア
if既存のスロットがトリプレット一致を含む
ストリーマIDを返す
end
end
既存のトリプレットがアクティブでなく、ストリーマを選択する必要がある
認定ストリーマの作成されたリスト
for全てのストリーマの全てのProxyRtspDsfeMediaインスタンス for要求されたネットワークおよび偏波に一致する全てのメディア
ifストリーマ負荷が所定最大帯域幅限界を超える
ストリーマをリストに含めない
ifメディアが既にFailedとマークされている
その失敗のタイムスタンプに基づいて(失敗の古いものから先に)ストリーマを順序付ける
else
小さなディザを現在の負荷統計値に付加する
その現在の負荷率統計値に基づいて(負荷の小さいものから先に)ストリーマを順序付ける
end
end
リストの最初のストリーマIDを返す
プロキシ・サーバ・ゲートウェイ20は、TCP接続数などのメトリクスに基づいて、クライアント・デバイス(例えばSTB35)の最大数を施行するものとする。好ましいデフォルト最大数は、クライアント・デバイスの接続数で500である。最大数に達すると、新たなTCP接続要求をサイレントに拒絶することができる。クライアント・デバイス数は、有効なSW License Keyから抽出した設定で置き換えることもできる。
プロキシ・サーバ・ゲートウェイ20とストリーマ・ゲートウェイ10の間のローカル・バス通信は、UDPを介して行うものとする(図2参照)。メッセージのタイプおよびフォーマットは、付録Aに列挙するが、コマンド文字列と、その後に続く1つまたは複数のパラメータ要求フィールドまたはパラメータ設定フィールドとからなるASCII可読フィールドを含むものとする。パラメータ・フィールドは、<CR><LF>によって区切られている。各メッセージは、コマンド・シーケンス番号(CSeq)フィールドおよびコンテンツ長(Content−length)フィールドを含むものとする。
プロキシ・サーバ・ゲートウェイ20は、3つのタイプのRTP Sessionメッセージをストリーマ・ゲートウェイ10に送信する。
プロキシ・サーバからストリーマへのメッセージ 用途
SessionAdd request ストリームを開始する
SessionUpdate request ストリームを更新する
SessionDelete request ストリームを停止する
ストリーマからプロキシ・サーバへのメッセージ 用途
Session request acknowledgement
メッセージの成功をトラッキングする
プロキシ・サーバ・ゲートウェイ20は、2つのタイプの状態要求メッセージをストリーマ・ゲートウェイ10に送信する。
プロキシ・サーバからストリーマへのメッセージ 用途
Streamer Status request ストリーマの負荷統計値およびトリプレットの状態を要求する
Session Status request トリプレットのRTPセッション状態を要求する
ストリーマからプロキシ・サーバへのメッセージ 用途
Streamer Status request response
プロキシ・サーバのストリーマ・データベースを更新する
Session Status request response
プロキシ・サーバのストリーマ・データベースを更新する
ストリーマ・ゲートウェイ10は、アクティブなトリプレットのリストを保持し、この情報を、Status Request応答メッセージに含めて戻す。割り当てられたトリプレットは、良好(St:D1)または失敗(St:D0)として報告される。チューナがロックを失ったとき、またはチューナを同調させることができないときには、ストリーマ・ゲートウェイ10は、自動的に別の空いているチューナを使用して、同調要求に応えようとするものとする。ストリーマ・ゲートウェイ10が全ての利用可能なチューナを試して失敗に終わった場合には、このトリプレットのStatus Requestエントリは、「失敗」(St:D0)を示すことになる。
プロキシ・サーバ・ゲートウェイ20は、失敗したトリプレットに関連する全てのRTPセッションをティアダウンし、クライアントRTSPクッキーをリセットするものとする。これらのクッキーは、クライアントRTSPセッションを、要求されたプログラムを担持するその下のRTPセッションと関係付けるものである。
各スロット資源は、監視カウンタを保持するものとする。このカウンタは、対応するトリプレットの状態をストリーマ・ゲートウェイ10から受信したときに、例えば3などの既定の数にリセットされる。ストリーマ・ゲートウェイ10がプロキシ・サーバ・ゲートウェイ20が以前に追加したトリプレットを肯定応答しない場合には、このカウンタは減分される。カウンタがゼロになると、スロットはタイムアウトし、以下の措置がとられるものとする。
・動的スロットの場合(すなわち関連するチューナが動的に同調される場合)には、プロキシ・サーバ・ゲートウェイ20は、SessionUpdateメッセージをストリーマ・ゲートウェイ10に送信して、全ての関連するRTPセッションのセッション更新を示すものとする。
・静的スロットの場合(関連するチューナが静的に同調される場合)には、プロキシ・サーバ・ゲートウェイ20は、このトリプレットについての全てのRTPセッションを内部で削除し、スロットを削除するものとする。
静的同調は、衛星ケーブル・フィードおよび/またはチューナ動作を妥当性検査するために使用されるトラブルシューティング・モードである。スロットのタイプ(静的/動的)およびトリプレットの状態を除けば、プロキシ・サーバ・ゲートウェイ20は、静的か動的かに係わらず、ストリーマ・ゲートウェイ10のチューナ割当てを管理またはトラッキングしないものとする。
ストリーマ・ゲートウェイ10のネットワーク・アナウンスメントは、239.255.255.255ポート19875など、既定のローカル・バス・マルチキャスト・グループに送信されるものとする。負荷分散をサポートするために、以下のストリーマ・ゲートウェイ10のSAPアナウンスメント機能が必要になることがある。
ストリーマ・アナウンスメントは、以下の新たなSDPセッション帯域幅属性を提供するものとする。
ストリーマ・メディア接続情報(c)は、実際には、ネットワークごとではなくストリーマごとに設定されるので、ネットワークSAPアナウンスメントSDPメディア属性接続情報(c)は、単一のSDPセッション属性となるものとする。マルチキャストの開始および範囲の情報は、MIB要素、mxulpServicesAddrMcastStartおよびmxulpServicesAddrMcastEndによって設定される。
アナウンスメントは、サポートされているネットワークと、所与の偏波設定でのチューナ数とを示すものとする。ネットワークSAPアナウンスメントSDPメディア属性X−dsfe−countは、以下のようなものとする。
例1:ストリーマ・ゲートウェイ10が、以下のように、(NW0L、NW15L+R、およびNW1H)用に構成される。
NW0L: チューナ1〜12。
NW15L: チューナ1〜12。チューナ数を2で割る(レガシー・チューナはカウントしない)。
NW15R: チューナ13〜24。チューナ数を2で割る(レガシー・チューナはカウントしない)。
NW1H: チューナ24〜32。
セッション・アナウンスメント・プロトコル
発信ソース:10.0.30.7
ペイロード・タイプ:アプリケーション/sdp
セッション記述プロトコル
セッション記述プロトコル・バージョン(v):0
所有者/作成者、セッションId(o):−0 1 IN IP4 10.0.30.7
セッション名(s):SERVICEPROVIDERNAME
セッション情報(i):SERVICEPROVIDERNAMEコンテンツ
接続情報(c):IN IP4 239.255.0.0/128/2048
帯域幅情報(b):X−load:100/800
メディア記述、名称およびアドレス(m):データ 1024 RTP/AVP 96
メディア・タイトル(i):ネットワーク0
メディア属性(a):control:rtsp://10.0.30.7/SERVICEPROVIDERNAME/ネットワーク0
メディア属性(a):X−dsfe−count:12/0
メディア記述、名称およびアドレス(m):データ 1024 RTP/AVP 33
メディア・タイトル(i):ネットワーク15
メディア属性(a):control:rtsp://10.0.30.7/SERVICEPROVIDERNAME/ネットワーク15
メディア属性(a):X−dsfe−count:6/6
メディア記述、名称およびアドレス(m):データ 1024 RTP/AVP 96
メディア・タイトル(i):ネットワーク1
メディア属性(a):control:rtsp://10.0.30.7/SERVICEPROVIDERNAME/ネットワーク1
メディア属性(a):X−dsfe−count:8/0
NW FFFE:4つのローカル・チャネルが利用可能であり、加えてプログラム・ガイド・チャネルがある。ストリーマ・ゲートウェイ10は、ベース・マルチキャストIPアドレス239.255.100.0を使用する。
セッション・アナウンスメント・プロトコル
発信ソース:10.0.30.3
ペイロード・タイプ:アプリケーション/sdp
セッション記述プロトコル
セッション記述プロトコル・バージョン(v):0
所有者/作成者、セッションId(o):−0 1 IN IP4 10.0.30.3
セッション名(s):SERVICEPROVIDERNAME
セッション情報(i):LOCALコンテンツ
接続情報(c):IN IP4 239.255.100.0/128/5
帯域幅情報(b):X−load:8000/8000
メディア記述、名称およびアドレス(m):データ 1024 RTP/AVP 33
メディア・タイトル(i):ネットワーク65534
メディア属性(a):control:rtsp://10.0.30.3/SERVICEPROVIDERNAME/ネットワーク65534
メディア属性(a):X−dsfe−count:5/0
ストリーマ・ゲートウェイ10は、そのSAPアナウンスメント・コンテンツを定期的に更新して、失敗チューナ情報または変更を帯域幅設定点に組み込むこともできる。プロキシ・サーバ・ゲートウェイ20は、それに応じてそのデータベースを更新することになる。
ゲートウェイ・リブートは、3つのカテゴリに分類される。
・全てのゲートウェイ10および20のリブート
・1つまたは複数のストリーマ・ゲートウェイ10のリブート
・プロキシ・サーバ・ゲートウェイ20のみのリブート
プロキシ・サーバ・ゲートウェイ20は、kRtspStreamerFailedメッセージおよびkRtspNewStreamerDetectedメッセージを使用して、ストリーマ・ゲートウェイ10の失敗および/またはリブートを示す。失敗ストリーマ・ゲートウェイ10は、ストリーマ・データベースから除去され、残りのストリーマ・ゲートウェイ10の間でデータ負荷が再分配されるものとする。同様に、新たに動作状態になったストリーマは、シームレスにデータベースに追加され、時間経過とともに、映像負荷がストリーマ・ゲートウェイ10の集団の中で再分配されるものとする。
設計目標は、プロキシ・サーバ・ゲートウェイ20のリブートによる映像の破壊を最小限に抑えることである。プロキシ・サーバ・ゲートウェイ20のブート・シーケンスは、以下の通りである。
1.ストリーマSAPアナウンスメントを検出する
2.検出された各ストリーマ・ゲートウェイ10について、
2.1 SESSIONDELETE(All)要求を送信し、全ての既存のストリーマセッションをティアダウンする
1.ストリーマ・ゲートウェイ10のSAPアナウンスメントを検出する
2.検出された各ストリーマ・ゲートウェイ10について、
2.1 STREAMERSTATUS要求を送信して、どのトリプレットがアクティブであるかを把握する
2.1.1 アクティブなトリプレットのそれぞれについて、SESSIONSTATUS要求を送信して、どのRTPセッションがアクティブであるかを把握する
3.プロキシ・サーバ・フロント・エンド(サービス・クライアント要求)をイネーブルする
(1つまたは複数の)LCI(ローカル・コンテンツ挿入)ストリーマ・ゲートウェイ10は、1つまたは複数の独立型PCおよび/またはダム(dumb)IPカメラであるものとする。予約PID(0xFF0−0xFFF)を含む任意のネットワークのクライアント・セットアップ要求は、通常のRTSPプロキシ・サーバ/ストリーマ動作をバイパスする。プロキシ・サーバ・ゲートウェイ20は、要求されたPIDおよびトランスポンダ番号に基づいてマルチキャスト・グループ・オフセットを決定するものとする。各ストリーマ・ゲートウェイ10(それぞれについてPIDが1つ予約される)は、トランスポンダの周波数設定あたり1つずつ、チャネル(マルチキャスト・グループ)を16個までサポートすることもできる。
プロキシ・サーバ・ゲートウェイ20は、イネーブルされるとローカル・コンテンツ・プログラム・ガイドを生成し、ストリーミングする、分離したアプリケーション・モジュールを提供するものとする。このアプリケーションは、ローカル・バス上のネットワークFFFE SAPアナウンスメントも生成して、ローカル・コンテンツ・ベース・マルチキャストIPアドレスを示すものとする。SAPアナウンスメント接続情報は、全てのストリーマ・ゲートウェイ10のローカル・コンテンツ・ベース・マルチキャストIPアドレスを示す。また、SAPアナウンスメント接続情報は、利用可能なローカル・チャネル数を示すこともできる。
PCストリーマ・ゲートウェイ10は、ネットワークFFFE用の、それ自体のストリーマSAPアナウンスメントを生成することになる。また、PCストリーマ・ゲートウェイ10は、ストリーマのマルチキャストの範囲内で、1つまたは複数のマルチキャスト・グループの最小のプログラム・ガイドも生成することになる。
ネットワークあたり1つのインスタンスが作成される。
プライベート・データ:
−ネットワーク・パス(セッション名およびメディア・タイトル)
−当該ネットワークをサポートするストリーマ・ゲートウェイ・インスタンスのリスト −当該ネットワークとともに使用中のメディア・クッキーのマップ
−その他
ストリーマ・ゲートウェイ10あたり1つのインスタンスが作成される。
プライベート・データ:
−ストリーマ・ゲートウェイ10のIPアドレスおよびサーバ・ポート
−帯域幅設定および現在の負荷統計値
−ストリーマ・ゲートウェイ10のキープアライブ・タイマ
−マルチキャスト・アドレス・ファクトリ・インスタンスptr
−ストリーマ・ネットワークあたり1つのProxyRtspDsfeMediaインスタンスのリスト
−ポート1554に束縛されたストリーマUDPソケットのファイル記述子
−その他
ネットワークあたりのストリーマ・ゲートウェイ10あたり1つのインスタンスが作成される。
プライベート・データ:
−メディア・タイトルおよびネットワーク番号
−RTSP統計値(数値設定、解析エラーなど)
−当該メディア・インスタンスのproxyRtpLibraryインスタンスptr −その他
クライアントRTSPセッションあたり1つのインスタンスが作成され、RtspServerConnectionインスタンスに格納される。
プライベート・データ:
−ストリーマ・インスタンスptr
−Triplet
−PidList
ストリーマ・ゲートウェイ10のトリプレットあたり1つのインスタンスが作成される。
プライベート・データ:
−当該スロットのDSFE設定
−Triplet
−スロット監視カウンタ
−TripletRtpSessionリスト
−スロット・タイプ(静的/動的)
−その他
ストリーマRTPセッションあたり1つのインスタンスが作成され、ストリーマ・スロット・リストに格納される。
プライベート・データ:
−関連するスロットのDSFE設定へのptr
−Triplet
−PidList
−マルチキャスト宛先アドレスおよびポート
−その他
ストリーマ・ゲートウェイ10あたり1つのインスタンスが作成される。
プライベート・データ:
−O/Sタイマ・インスタンス
−タイマ・リロード値
検出されたストリーマ・ゲートウェイ10あたり1つのインスタンスが作成される。
プライベート・データ:
−データ・バッファ、ストリーマ・ゲートウェイ10からの最も最近のSAPアナウンスメントを保持する
プロキシ・サーバ・ゲートウェイ20は、SAPリスナ・モジュールを実施しなければならない。このモジュールは、以下の新たなメッセージ・タイプを、プロキシRTSPサーバ・モジュールに送信する。
・ストリーマ・ゲートウェイ10SAPアナウンスメント受信
・ストリーマ・ゲートウェイ10SAPアナウンスメント・タイムアウト
前述のように、プロキシRTSPサーバ・モジュールは、1.xRtspDsfeMediaクラスの代わりに、新たなStreamerクラス、RtspStreamerMediaクラス、およびProxyRtspDsfeMediaクラスを使用しなければならない。
・SAPリスナ・モジュール・メッセージのサポートを提供しなければならない
・集合体ネットワークSAPアナウンスメントを生成しなければならない
・ストリーマ・ゲートウェイ10のメッセージを送受信するためのメッセージング機能を実施しなければならない
・その他
各ストリーマ・ゲートウェイ10は、ローカル・バス・ソケットを監視するモジュールを実施する。このモジュールは、一般に、以下のようにRTSPスタックをエミュレートする。
・存在する各ネットワークについて、RtspDsfeMediaおよびRTPLibraryインスタンスを作成する
・RtspSessionおよびRtspDsfeMedia構成ファイル設定に基づいて、ローカル・バス上のネットワークSAPアナウンスメントを生成する
・例えばポート1554のローカル・バスUDPソケットを作成する
・プロキシ・サーバ・ゲートウェイ20のメッセージを送受信するメッセージング機能を実施する
・プロキシ・サーバRTPセッション要求をフィールディング(field)する
・チューナおよびFPGA/データ・ポンプの機能性を管理する
ブート時には、以下の構成ファイル/SNMP MIBパラメータを確認して、ゲートウェイを構成する。
・mxuNetworkAuditAdminEnabled
mxuRtspServerConfigStreamerCountは、ブート時にプロキシ・サーバ・ゲートウェイ20によって使用されて、システム内のストリーマ・ゲートウェイ10の予想数を示す。プロキシ・サーバ・ゲートウェイ20は、mxuRtspServerConfigStreamerCountに一意的なSAPアナウンスメントを受信するまで、または2分など既定の間隔が経過するまで、集合体ネットワークSAPアナウンスメントを遅延させる。
これらのAPIは、大域的にアクセス可能なAPIである。
この機能は、構成ファイル・パラメータmxuRtspServerConfigProxyEnableのブート状態を戻す。
この機能は、ブート時に1つまたは複数のアクティブなmxuRtspDsfeMediaConfigRowStatus構成ファイル・エントリがある場合に、真を戻す。
さらに、少なくとも1つのアクティブなmxuRtspSessionConfigRowStatusエントリが存在しなければならない。
この機能は、mxuStreamerConfigStreamerEnableおよびisStreamer()が両方とも真である場合に、真を戻す。
すなわち、要求されたプログラムがネットワーク上でストリーマ・ゲートウェイ10の1つから既に入手可能であると仮定すると、プロキシ・サーバ・ゲートウェイ20からの応答メッセージは、STB35が要求したプログラムにアクセスするために使用することができるマルチキャスト・ネットワーク・アドレスを含むことができる。
Sessionメッセージは、以下のフォーマットで構成される。各行は、<CR><LF>で終了する。
コマンド要求/応答識別子の行
ヘッダ・パラメータ、行あたり1つ
<CR><LF>分離記号は、ヘッダの終了を示す
ペイロード・パラメータ、行あたり1つ
<CR><LF>分離記号は、ペイロードの終了を示す
この要求は、全てのフィールドを含んでいなければならない。順序は重要でない。全てのフィールドが、ASCIIテキストである。
SESSIONADD/Request
CSeq: int
Content−length: int
MediaPath: RtspSessionName/network###
Triplet: 32ビット16進数:0xzzzzzzzzFrequency: 32ビットunsigned int
Polarization: lhcp、rhcp、水平、垂直
Standard: dss、dvbs、dvbs2、amc
Modulation: qpsk、8psk
Symbol−Rate: 32ビットunsigned int
Code−Rate: 2−3、6−7など
Alpha: int(0、1、または2)
Pilot: 真、偽
Gold−Code: int
Amc−Mode: int
PLS: 12の16進数字 010203040506070809101112
Xport−Packets: int
Low−Jitter: 真、偽
Pids: int、int、int、…
Destination−Address:xx.xx.xx.xx
Destination−Port: int
この応答は、任意選択であるStatusReasonを除く全てのフィールドを含んでいなければならない。
SESSIONADD/Response
CSeq: int
Content−length:int
Triplet: 32ビット16進数:0xzzzzzzzz
Status: int(0=成功)
StatusReason: ASCII文字列
Errors: 100=メッセージ解析エラーです
101=基本パラメータが足りません
102=メディアが利用できません
103=セッション割当てに失敗しました
この要求は、トリプレットおよび宛先アドレス、ならびに更新すべきその他のdsfe/セッション・フィールドを含むものとする。順序は重要でない。
SESSIONUPDATE/Request
CSeq: int
Content−length: int
MediaPath: RtspSessionName/network###
Triplet: 32ビット16進数:0xzzzzzzzzFrequency: 32ビットunsigned int
Polarization: lhcp、rhcp、水平、垂直
Standard: dss、dvbs、dvbs2、amc
Modulation: qpsk、8psk
Symbol−Rate: 32ビットunsigned int
Code−Rate: 2−3、6−7など
Alpha: int(0、1、または2)
Pilot: 真、偽
Gold−Code: int
Amc−Mode: int
PLS: 12の16進数字 010203040506070809101112
Xport−Packets: int
Low−Jitter: 真、偽
Pids: int、int、int、…
Destination−Address:xx.xx.xx.xx
Destination−Port: int
この応答は、任意選択であるStatusReasonを除く全てのフィールドを含んでいなければならない。
SESSIONUPDATE/Response
CSeq: int
Content−length:int
Triplet: 32ビット16進数:0xzzzzzzzz
Status: int(0=成功)
StatusReason: ASCII文字列
Errors: 100=メッセージ解析エラーです
101=基本パラメータが足りません
102=メディアが利用できません
103=セッション割当てに失敗しました
104=セッションが見つかりません
この要求は、トリプレットおよび宛先アドレスを識別する。
宛先アドレスが255.255.255.255である場合には、ストリーマ・ゲートウェイ10は、要求されたトリプレットに関連する全てのRTPセッションを削除し、チューナ資源を解放しなければならない。
トリプレット値が0xFFFFFFFFであり、宛先アドレスが255.255.255.255である場合には、ストリーマ・ゲートウェイ10は、全てのRTPセッションを削除し、このストリーマ・ゲートウェイ10上の全てのトリプレット(チューナ資源)を解放しなければならない。
SESSIONDELETE/Request
CSeq: int
Content−length: int
Triplet: 32ビット16進数:0xzzzzzzzzDestination−Address:xx.xx.xx.xx
この応答は、任意選択であるStatusReasonを除く全てのフィールドを含んでいなければならない。
SESSIONDELETE/Response
CSeq: int
Content−length:int
Triplet: 32ビット16進数:0xzzzzzzzz
Status: int(0=成功)
StatusReason: ASCII文字列
Errors: 100=メッセージ解析エラーです
101=基本パラメータが足りません
102=メディアが利用できません
104=セッションが見つかりません
Statusメッセージは、以下のフォーマットで構成される。各行は、<CR><LF>で終了する。
コマンド要求/応答識別子の行
ヘッダ・パラメータ、行あたり1つ
<CR><LF>分離記号は、ヘッダの終了を示す
ペイロード・パラメータ、行あたり1つ
<CR><LF>分離記号は、ペイロードの終了を示す
この要求は、関連のあるフィールドを識別する。
STREAMERSTATUS/Request
CSeq: int
Content−length:int
LoadStat:
NumTriplets:
Nw:
Po:
Fr:
St:
ストリーマ・ゲートウェイ10は、要求された負荷統計値と、それに続くトリプレット状態エントリの配列とを含む応答メッセージを生成することになる。戻されるエントリの数は、NumTripletsで指定される。
・1番目の文字は、静的同調を示すS、または動的同調を示すDである。
・2番目/3番目の文字は、成功を示す1から32、または失敗を示す0(ゼロ)である。
動的同調時には、状態フィールドは、1(良好)または0(失敗)チューナを示さなければならない。
STREAMERSTATUS/Response
CSeq: int
Content−length:int
LoadStat: 283
NumTriplets: 3
Nw: 0
Po: 2
Fr: 988
St: D1
Nw: 0
Po: 3
Fr: 974
St: D1
Nw: 0
Po: 2
Fr: 1267
St: S5
メッセージ応答は、ストリーマが32個の一意的なトリプレットについての状態を報告するときに、最大となる。
このメッセージは、メディア・パス値、トリプレット値、および少なくとも1つの追加要求フィールドを含んでいなければならない。
SESSIONSTATUS/Request
CSeq: int
Content−length:int
MediaPath: RtspSessionName/network###
Triplet: 32ビット16進数:0xzzzzzzzz
NumSessions:
Frequency:
Polarization:
Standard:
Modulation:
Symbol−Rate:
Code−Rate:
Alpha:
Pilot:
Gold−Code:
Amc−Mode:
PLS:
Xport−Packets:
Low−Jitter:
Pids:
Destination−Address:
Destination−Port:
セッション状態要求メッセージで要求されるフィールドは、応答メッセージに含まれていなければならない。要求されたトリプレットについての全てのセッションは、1つの応答メッセージで送信される。戻されるセッションの数は、NumSessionsで指定される。セッションは、(PID、宛先アドレス、宛先ポート)の3つの要素でグループ化される。また、トリプレットがA3モードのチューナに関連する場合のみ、A3パラメータ要求フィールド(alpha、pilot、gold−code、amc−mode、およびpls)が戻されることにも留意されたい。
SESSIONSTATUS/Response
CSeq: int
Content−length: int
MediaPath: RtspSessionName/network###
Triplet: 32ビット16進数:0xzzzzzzzzFrequency: 32ビットunsigned int
Polarization: lhcp、rhcp、水平、垂直
Standard: dss、dvbs、dvbs2、amc
Modulation: qpsk、8psk
Symbol−Rate: 32ビットunsigned int
Code−Rate: 2−3、6−7など
Alpha: int(0、1、または2)
Pilot: 真、偽
Gold−Code: int
Amc−Mode: int
PLS: 12の16進数字 010203040506070809101112
Xport−Packets: int
Low−Jitter: 真、偽
NumSessions: 3
Pids: int、int、int
Destination−Address:xx.xx.xx.xx
Destination−Port: int
SESSIONSTATUS/Response
CSeq: xxx
Content−length: yyy
MediaPath: SERVICEPROVIDERNAME/network0
Triplet: 0x00020549
NumSessions: 3
Frequency: 1353080000
Polarization: rhcp
Standard: dss
Modulation: qpsk
Symbol−Rate: 20000000
Code−Rate: 6−7
Xport−Packets: 10
Low−Jitter: 偽
Pids: 10、11
Destination−Address:239.255.0.17
Destination−Port: 1024
Pids: 30、31
Destination−Address:239.255.2.138
Destination−Port: 1024
Pids: 90、91、92
Destination−Address:239.255.0.48
Destination−Port: 1024
A.1.1 一部のチューナが影響を受ける場合
ストリーマ・ゲートウェイ10がチューナのロック解除を検出し、空いているチューナが利用可能である場合には、ストリーマ・ゲートウェイ10は、そのシャーシ内の空いているチューナにRTPセッションを移動させることになる。プロキシ・サーバ・ゲートウェイ20は、この移動を知る必要はない。シャーシ内に利用可能な空いているチューナがない、または空いているチューナ全てを試して失敗した場合には、ストリーマは、次のSTREAMERSTATUS応答メッセージでトリプレット失敗を示す。ストリーマ・ゲートウェイ10は、失敗であることを示したら、セッションの移動の試行を停止しなければならない。ストリーマ・ゲートウェイ10がトリプレット同調失敗を示したら、プロキシ・サーバ・ゲートウェイ20は、そのトリプレットを別のストリーマにリダイレクトすることになる。
全てのチューナが降雨減衰でロック解除する可能性もある。これは、全てのストリーマ・ゲートウェイ10の間で起こる可能性がある。STREAMERSTATUS応答に基づいて、プロキシ・サーバ・ゲートウェイ20は、ストリーマ・ゲートウェイ10のトリプレット(スロット)をエラーとマークし、スロットの時間を現在の時間に更新する。ストリーマの間で空いているスロットがない場合には、プロキシは、新たなセットアップ要求を、最も古いエラー・スロットを有するストリーマ・ゲートウェイ10に転送することになる。プロキシ・サーバ・ゲートウェイ20が全てのエラー・スロットを試し、それでもなおSTREAMERSTATUSが失敗を示し続ける場合には、プロキシ・サーバ・ゲートウェイ20は、503:Service Unavailableメッセージを、クライアント・デバイス(例えばSTB35)に送信することができる。現在のSTBソフトウェアは、503:ServiceUnavailable応答の受信時にその挙動が変化しない。そうなるまでは、ここで提案する動作は、新たな価値を付加しない。
静的同調チューナがロックできない、またはロックを失った場合には、ストリーマは、STREAMERSTATUS応答メッセージ中でSt:S0失敗を示さない。ストリーマは、引き続きSt:S1を示し続ける。ストリーマは、引き続き、当該静的同調チューナの回復を試行し続けなければならない。
プロキシ・サーバ・ゲートウェイ20のリブート中には、全てのクライアントSTBクッキーが失われる。リブートに続いて、プロキシ・サーバ・ゲートウェイ20は、454:Session Not Foundを送って、以前の(且つ現在は未知の)RTSPセッション番号を含むSetup要求を発行したSTBに応答する。しかし、実際の動作では、これは問題にならないものと考えられる。プロキシ・サーバ・ゲートウェイ20がダウンしている間に、STB TCP接続がリセットされ、STBが、RTSPセッション番号を含まない新たなセットアップ要求を発行するからである。
1.静的チューナが解放された場合
a.当該チューナのRTPセッションが存在しない場合には、当該チューナはサイレントにプールに戻される。ストリーマ・ゲートウェイ10は、St:S1の報告を停止する。解放された静的チューナを検出し、静的スロットを削除する以外には、プロキシ・サーバ・ゲートウェイ20が動作を起こす必要はない。
b.RTPセッションが存在する場合には、ストリーマ・ゲートウェイ10は、動的チューナが利用可能であれば、トリプレットおよびセッションを動的チューナにサイレントに移動させる。プロキシ・サーバ・ゲートウェイ20は、以前の静的スロットを動的スロットとしてマークしなければならない。
c.RTPセッションが存在するが、移動に失敗した場合には、ストリーマ・ゲートウェイ10は、トリプレット失敗(D0)エントリを含むStreamerStatus/Responseメッセージを、プロキシ・サーバ・ゲートウェイ20に送信しなければならない。
a.トリプレット状態は、新たに静的に同調されたチューナを示すようになる。プロキシ・サーバ・ゲートウェイ20は、以前の動的スロットを静的スロットとしてマークしなければならない。
b.利用可能であれば、ストリーマ・ゲートウェイ10は、動的RTPセッションを空いているチューナにサイレントに移動させる。トリプレット状態は、引き続き、動的同調チューナを示し続ける。
c.空いているチューナが利用可能でない場合には、ストリーマ・ゲートウェイ10は、移動させることができない動的トリプレットについて「D0」状態を戻す。プロキシ・サーバ・ゲートウェイ20は、このトリプレットに関する全てのRTSPセッションをティアダウンする。
1.ストリーマ・ゲートウェイ10が、プロキシ・サーバ・ゲートウェイ20には未知のトリプレットの失敗を状態応答の中で報告した場合には、プロキシ・サーバ・ゲートウェイ20は、当該トリプレットに関連する全てのセッションをティアダウンする。(プロキシは、当該トリプレットおよびDestinationAddress=255.255.255.255を有するSessionDeleteメッセージを送信する。)
以下に、本発明の好ましい態様を示す。
付記1.複数の映像ソースの1つの映像をダウンロードすることを求める要求をクライアント・デバイスから受信するステップ(510)と、
前記複数の映像ソースを受信することができる第1の映像受信側デバイスおよび第2の映像受信側デバイスからそれぞれの負荷指標を受信するステップ(530)と、
前記負荷指標に従って、前記第1の映像受信側デバイスおよび前記第2の映像受信側デバイスの一方を選択するステップ(540)と、
前記選択した映像受信側デバイスに、前記複数の映像ソースの1つの前記映像を、前記クライアント・デバイスが知っているアドレスを使用して伝送するように命令するステップ(550)とを含む、方法(500)。
付記2.前記選択した映像受信側デバイスに前記アドレスを提供するステップをさらに含む、付記1に記載の方法(500)。
付記3.前記第1の映像受信側デバイスおよび前記第2の映像受信側デバイスの一方がマルチキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記1つの前記映像を受信することができるようにするステップをさらに含む、付記1に記載の方法(500)。
付記4.前記第1の映像受信側デバイスおよび前記第2の映像受信側デバイスの一方がユニキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記送信している映像受信側デバイスに、ユニキャストをマルチキャストに変換するように要求し、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの1つの前記映像を受信することができるようにするステップをさらに含む、付記1に記載の方法(500)。
付記5.それぞれの負荷指標を受信する前記ステップが、定期的に実行される、付記1に記載の方法(500)。
付記6.前記それぞれの負荷指標が、前記第1の映像受信側デバイスおよび前記第2の映像受信側デバイスそれぞれの負荷率設定点を示す、付記1に記載の方法(500)。
付記7.前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記1に記載の方法(500)。
付記8.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスの方が負荷が軽い、付記1に記載の方法(500)。
付記9.複数の映像ソースの1つの映像をダウンロードすることを求める要求をクライアント・デバイス(35)から受信する手段(21)と、
前記複数の映像ソースを受信することができる第1の映像受信側デバイス(10)および第2の映像受信側デバイス(10)からそれぞれの負荷指標を受信する手段(22)と、
前記負荷指標に従って、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方を選択する手段と、
前記選択した映像受信側デバイス(10)に、前記複数の映像ソースの1つの前記映像を、前記クライアント・デバイス(35)が知っているアドレスを使用して伝送するように命令する手段とを備える、装置(20)。
付記10.前記選択した映像受信側デバイス(10)に前記アドレスを提供する手段をさらに備える、付記9に記載の装置(20)。
付記11.前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方がマルチキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記クライアント・デバイス(35)にマルチキャスト・ネットワーク・アドレスが送信され、前記クライアント・デバイス(35)が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記1つの前記映像を受信することができるようにする、付記9に記載の装置(20)。
付記12.前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方がユニキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記送信している映像受信側デバイス(10)が、前記ユニキャストをマルチキャストに変換し、前記クライアント・デバイス(35)にマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイス(35)が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの1つの前記映像を受信することができるようにする、付記9に記載の装置(20)。
付記13.それぞれの負荷指標が、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)から定期的に受信される、付記9に記載の装置(20)。
付記14.前記それぞれの負荷指標が、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)それぞれの負荷率設定点を示す、付記9に記載の装置(20)。
付記15.前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記9に記載の装置(20)。
付記16.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス(10)の方が負荷が軽い、付記9に記載の装置(20)。
付記17.複数の映像ソースの1つの映像をダウンロードすることを求める要求をクライアント・デバイス(35)から受信するように動作可能な第1の入力(21)と、
前記複数の映像ソースを受信することができる第1の映像受信側デバイス(10)および第2の映像受信側デバイス(10)からそれぞれの負荷指標を受信するように動作可能な第2の入力(22)と、
前記負荷指標に従って、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方を選択するように動作可能な第1の制御論理と、
前記選択した映像受信側デバイス(10)に、前記複数の映像ソースの1つの前記映像を、前記クライアント・デバイス(35)が知っているアドレスを使用して伝送するように命令するように動作可能な第2の制御論理とを備える、装置(20)。
付記18.前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方がマルチキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記クライアント・デバイス(35)にマルチキャスト・ネットワーク・アドレスが送信され、前記クライアント・デバイス(35)が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記1つの前記映像を受信することができるようにする、付記17に記載の装置(20)。
付記19.前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)の一方がユニキャストを使用して前記複数の映像ソースの1つの映像を送信している場合に、前記送信している映像受信側デバイス(10)が、ユニキャストをマルチキャストに変換し、前記クライアント・デバイス(35)にマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイス(35)が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの1つの前記映像を受信することができるようにする、付記17に記載の装置(20)。
付記20.前記それぞれの負荷指標が、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)から定期的に受信される、付記17に記載の装置(20)。
付記21.前記それぞれの負荷指標が、前記第1の映像受信側デバイス(10)および前記第2の映像受信側デバイス(10)それぞれの負荷率設定点を示す、付記17に記載の装置(20)。
付記22.前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記17に記載の装置(20)。
付記23.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス(10)の方が負荷が軽い、付記17に記載の装置(20)。
付記24.複数の映像ソースを受信することができる映像受信側デバイスから要求サーバ・デバイスに、前記映像受信側デバイスに関連する負荷を示す負荷指標を送信するステップ(610)と、
要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイスの宛先アドレスを示すデータを、前記要求サーバ・デバイスから受信するステップ(620)と、
前記要求されたプログラムを前記宛先アドレスに伝送するステップ(630)とを含む、方法(600)。
付記25.前記映像ソースがそれぞれ、テレビジョン・チャネルである、付記24に記載の方法(600)。
付記26.前記負荷指標が、前記映像受信側デバイスに関連する負荷率を示す、付記24に記載の方法(600)。
付記27.前記受信ステップが、前記映像受信側デバイスが複数の異なる映像受信側デバイスの中で最も低い負荷を有すると前記要求サーバ・デバイスが判定したのに応答して実行される、付記24に記載の方法(600)。
付記28.前記送信ステップが、定期的に実行される、付記24に記載の方法(600)。
付記29.装置(10)に関連する負荷を示す負荷指標を決定する手段と、
前記負荷指標を要求サーバ・デバイス(20)に送信する手段(11)とを備え、
前記負荷指標に応じて、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイス(35)の宛先アドレスを示すデータが前記要求サーバ・デバイス(20)から受信され、前記装置(10)が前記要求されたプログラムを前記宛先アドレスに伝送する、装置(10)。
付記30.前記装置(10)が、複数のテレビジョン・チャネルを受信することができる、付記29に記載の装置(10)。
付記31.前記負荷指標が、前記装置(10)に関連する負荷率を示す、付記29に記載の装置(10)。
付記32.前記装置(10)が複数の異なる装置(10)の中で最も低い負荷を有すると前記要求サーバ・デバイス(20)が判定したのに応答して、前記要求されたプログラムおよび前記要求されたプログラムに関連する前記クライアント・デバイス(35)の宛先アドレスが前記要求サーバ・デバイス(20)から受信される、付記29に記載の装置(10)。
付記33.前記複数の異なる装置(10)が、映像受信側デバイスである、付記32に記載の装置(10)。
付記34.前記負荷指標が、定期的に前記要求サーバ・デバイス(20)に送信される、
付記29に記載の装置(10)。
付記35.装置(10)に関連する負荷を示す負荷指標を決定するように動作可能な制御論理と、
前記負荷指標を要求サーバ・デバイス(20)に送信するように動作可能なインタフェース(11)とを備え、
前記負荷指標に応じて、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイス(35)の宛先アドレスを示すデータが前記要求サーバ・デバイス(20)から受信され、前記装置(10)が前記要求されたプログラムを前記宛先アドレスに伝送する、装置(10)。
付記36.前記装置(10)が、複数のテレビジョン・チャネルを受信することができる、付記35に記載の装置(10)。
付記37.前記負荷指標が、前記装置(10)に関連する負荷率を示す、付記35に記載の装置(10)。
付記38.前記装置(10)が複数の異なる装置(10)の中で最も低い負荷を有すると前記要求サーバ・デバイス(20)が判定したのに応答して、前記要求されたプログラムおよび前記要求されたプログラムに関連する前記クライアント・デバイス(35)の宛先アドレスが前記要求サーバ・デバイス(20)から受信される、付記35に記載の装置(10)。
付記39.前記複数の異なる装置(10)が、映像受信側デバイスである、付記38に記載の装置(10)。
付記40.前記負荷指標が、定期的に前記要求サーバ・デバイス(20)に送信される、付記35に記載の装置(10)。
付記41.プログラムを求める要求をクライアント・デバイスから要求サーバ・デバイスに送信するステップ(710)と、
前記要求に応答して、前記クライアント・デバイスが前記要求サーバ・デバイスからアドレスを受信するステップ(720)と、
前記アドレスを使用して、選択された映像受信側デバイスを介して、前記クライアント・デバイスが前記要求したプログラムを受信するステップ(730)とを含み、
前記要求サーバ・デバイスが、前記選択された映像受信側デバイスを、複数の映像受信側デバイスの中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、方法(700)。
付記42.前記それぞれの負荷指標が、前記複数の映像受信側デバイスそれぞれの負荷率設定点を示す、付記41に記載の方法(700)。
付記43.前記複数の映像受信側デバイスが、複数のテレビジョン・チャネルに同調することができる、付記41に記載の方法(700)。
付記44.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスはより軽い負荷を有する、付記41に記載の方法(700)。
付記45.プログラムを求める要求を要求サーバ・デバイス(20)に送信する手段と、
前記要求に応答して、前記要求サーバ・デバイス(20)からアドレスを受信する手段と、
前記アドレスを使用して、選択された映像受信側デバイス(10)を介して、前記要求したプログラムを受信する手段とを備え、
前記要求サーバ・デバイス(20)が、前記選択された映像受信側デバイス(10)を、複数の映像受信側デバイス(10)の中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、装置(35)。
付記46.前記それぞれの負荷指標が、前記複数の映像受信側デバイス(10)それぞれの負荷率設定点を示す、付記45に記載の装置(35)。
付記47.前記複数の映像受信側デバイス(10)が、複数のテレビジョン・チャネルにそれぞれ同調することができる、付記45に記載の装置(35)。
付記48.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス(10)はより軽い負荷を有する、付記45に記載の装置(35)。
付記49.プログラムを求める要求を要求サーバ・デバイス(20)に送信するように動作可能な出力と、
前記要求に応答して、前記要求サーバ・デバイス(20)からアドレスを受信し、前記アドレスを使用して、選択された映像受信側デバイス(10)を介して、前記要求したプログラムを受信するように動作可能な入力とを備え、
前記要求サーバ・デバイス(20)が、前記選択された映像受信側デバイス(10)を、複数の映像受信側デバイス(10)の中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、装置(35)。
付記50.前記それぞれの負荷指標が、前記複数の映像受信側デバイス(10)それぞれの負荷率設定点を示す、付記49に記載の装置(35)。
付記51.前記複数の映像受信側デバイス(10)が、複数のテレビジョン・チャネルにそれぞれ同調することができる、付記49に記載の装置(35)。
付記52.前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス(10)はより軽い負荷を有する、付記49に記載の装置(35)。
Claims (6)
- プロキシ・サーバ・ゲートウェイである要求サーバ・デバイスと、それぞれが複数のチャネルに同調することができる個別のチューナを有する複数の映像受信側デバイスとを備えるシステムにおいて、クライアント・デバイスにより行われる方法であって、前記複数の映像受信側デバイスは、前記クライアント・デバイスに映像を伝送する機能を提供するゲートウェイであり、前記要求サーバ・デバイスは、クライアント・デバイスからの要求を処理するために前記映像受信側デバイスのそれぞれの負荷指標に基づいて前記複数の映像受信側デバイスの一つを選択し、
前記複数のチャネルのうちの1つにより伝送されたプログラムを求める要求をクライアント・デバイスから前記要求サーバ・デバイスに送信するステップと、
前記要求に応答して、前記クライアント・デバイスが前記要求サーバ・デバイスからアドレスを受信するステップと、
前記アドレスを使用して、選択された映像受信側デバイスを介して、前記クライアント・デバイスが前記要求したプログラムを受信するステップであって、前記選択した映像受信側デバイスは、前記プロキシ・サーバ・ゲートウェイを回避して前記映像を前記クライアント・デバイスに伝送する、ステップと、
を含む、前記方法。 - 前記それぞれの負荷指標が、前記複数の映像受信側デバイスに対しそれぞれの負荷率設定点を示す、請求項1に記載の方法。
- 前記複数の映像受信側デバイスが、それぞれ複数のテレビジョン・チャネルに同調することができる、請求項1に記載の方法。
- 前記選択された映像受信側デバイスは、前記それぞれの負荷指標によれば、より軽い負荷を有する、請求項1に記載の方法。
- 前記アドレスは、マルチキャスト・ネットワーク・アドレスである、請求項1に記載の方法。
- 請求項1乃至5のいずれか1項に記載の方法を行う、装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US6758508P | 2008-02-29 | 2008-02-29 | |
US61/067,585 | 2008-02-29 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010548654A Division JP5503560B2 (ja) | 2008-02-29 | 2008-12-12 | 負荷分散信号分配を行う方法および装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2014147088A JP2014147088A (ja) | 2014-08-14 |
JP5873124B2 true JP5873124B2 (ja) | 2016-03-01 |
Family
ID=40403982
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010548654A Expired - Fee Related JP5503560B2 (ja) | 2008-02-29 | 2008-12-12 | 負荷分散信号分配を行う方法および装置 |
JP2014051879A Expired - Fee Related JP5873124B2 (ja) | 2008-02-29 | 2014-03-14 | 負荷分散信号分配を行う方法および装置 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010548654A Expired - Fee Related JP5503560B2 (ja) | 2008-02-29 | 2008-12-12 | 負荷分散信号分配を行う方法および装置 |
Country Status (7)
Country | Link |
---|---|
US (1) | US9015781B2 (ja) |
EP (1) | EP2260636A1 (ja) |
JP (2) | JP5503560B2 (ja) |
KR (1) | KR101531960B1 (ja) |
CN (2) | CN105306586A (ja) |
BR (1) | BRPI0822217B1 (ja) |
WO (1) | WO2009108176A1 (ja) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5503560B2 (ja) * | 2008-02-29 | 2014-05-28 | トムソン ライセンシング | 負荷分散信号分配を行う方法および装置 |
US20100058424A1 (en) * | 2008-08-26 | 2010-03-04 | Comcast Cable Holdings, Llc | System and method for controlling signal traffic peaks on a video interactive network |
US8555322B2 (en) | 2009-01-23 | 2013-10-08 | Microsoft Corporation | Shared television sessions |
EP2540037B1 (en) * | 2010-02-23 | 2023-08-02 | LG Electronics Inc. | A method and an apparatus for session routing in home network system |
US8379562B2 (en) * | 2010-10-12 | 2013-02-19 | Ian Pitts | Paging relay controller and methods thereof |
CN102624651A (zh) * | 2012-03-08 | 2012-08-01 | 北京神州数码思特奇信息技术股份有限公司 | 网关通信方法及装置 |
US8943543B2 (en) | 2012-08-09 | 2015-01-27 | Charter Communications Operating, Llc | System and method bridging cloud based user interfaces |
FR3011415A1 (fr) * | 2013-10-01 | 2015-04-03 | Orange | Procede de diffusion d'identifiants de sources multicast |
US10033616B1 (en) * | 2014-03-27 | 2018-07-24 | Juniper Networks, Inc. | State synchronization for global control in a distributed security system |
CN104980803A (zh) * | 2015-07-29 | 2015-10-14 | 深圳市芯智科技有限公司 | 一种自主中间件智能dvbs2机顶盒系统及处理方法 |
CN107241374B (zh) | 2016-03-28 | 2020-01-31 | 财团法人工业技术研究院 | 负载平衡系统、负载平衡装置及拓朴管理方法 |
US10432709B2 (en) | 2016-03-28 | 2019-10-01 | Industrial Technology Research Institute | Load balancing method, load balancing system, load balancing device and topology reduction method |
CN107920045A (zh) * | 2016-10-08 | 2018-04-17 | 中兴通讯股份有限公司 | 一种会话描述协议消息生成方法和装置 |
Family Cites Families (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5633810A (en) * | 1995-12-14 | 1997-05-27 | Sun Microsystems, Inc. | Method and apparatus for distributing network bandwidth on a media server |
US6195680B1 (en) | 1998-07-23 | 2001-02-27 | International Business Machines Corporation | Client-based dynamic switching of streaming servers for fault-tolerance and load balancing |
US6986156B1 (en) * | 1999-06-11 | 2006-01-10 | Scientific Atlanta, Inc | Systems and methods for adaptive scheduling and dynamic bandwidth resource allocation management in a digital broadband delivery system |
WO2001022688A1 (en) * | 1999-09-21 | 2001-03-29 | Streaming21, Inc. | Method and system for providing streaming media services |
US6678740B1 (en) * | 2000-01-14 | 2004-01-13 | Terayon Communication Systems, Inc. | Process carried out by a gateway in a home network to receive video-on-demand and other requested programs and services |
US7133922B1 (en) * | 2000-08-07 | 2006-11-07 | The Hong Kong University Of Science And Technology | Method and apparatus for streaming of data |
US6990338B2 (en) * | 2001-06-11 | 2006-01-24 | The Boeing Company | Mobile wireless local area network and related methods |
EP1407356B1 (en) * | 2001-07-03 | 2016-09-07 | Accenture Global Services Limited | Broadband communications |
US20030174648A1 (en) * | 2001-10-17 | 2003-09-18 | Mea Wang | Content delivery network by-pass system |
US20090222875A1 (en) | 2002-04-18 | 2009-09-03 | Cheng David J | Distributed tuner allocation and conflict resolution |
US7296069B2 (en) * | 2002-05-08 | 2007-11-13 | Hewlett-Packard Development Company, L.P. | Method and system for network fault monitoring with linux |
JP3809813B2 (ja) * | 2002-08-21 | 2006-08-16 | 日本電信電話株式会社 | コンテンツ配信方法およびこれを用いるコンテンツ配信システム |
JP2004158969A (ja) * | 2002-11-05 | 2004-06-03 | Nec Corp | 映像システム、映像装置、プログラム |
US6947403B2 (en) | 2003-06-27 | 2005-09-20 | Nokia Corporation | Advanced whitener-rake receiver for WCDMA terminal |
US9807460B2 (en) * | 2003-08-11 | 2017-10-31 | Arris Enterprises, Inc. | Optimal provisioning and management of bandwidth in a video-on-demand services architecture |
US7554954B2 (en) * | 2003-08-12 | 2009-06-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Per user rate control for the reverse link in CDMA networks |
US20050250511A1 (en) | 2004-05-05 | 2005-11-10 | Weimin Xiao | Method for rate control signaling to facilitate UE uplink data transfer |
CN101084682A (zh) * | 2004-05-05 | 2007-12-05 | 摩托罗拉公司 | 用于速率控制信令以促进ue上行链路数据传输的方法 |
US8370888B2 (en) * | 2004-06-22 | 2013-02-05 | University Of Southern California | Hydra: high-performance data recording architecture for streaming media |
EP1619853A1 (en) | 2004-07-21 | 2006-01-25 | Siemens Mobile Communications S.p.A. | RTSP proxy extended to detect streaming session events and report to valued streaming applications the notified ones |
JP2008508807A (ja) * | 2004-07-30 | 2008-03-21 | 松下電器産業株式会社 | 分散共有およびライブテレビ録画のためのシステムおよび方法 |
US7380264B2 (en) * | 2004-08-13 | 2008-05-27 | Microsoft Corporation | Systems for unifying heterogeneous multimedia tuners |
CN101091175B (zh) * | 2004-09-16 | 2012-03-14 | 辉达公司 | 负载均衡 |
MX2007008251A (es) * | 2005-01-05 | 2007-08-22 | Thomson Licensing | Un metodo y sistema para asignar recursos de recepcion en un servidor de pasarela. |
FR2884669A1 (fr) * | 2005-04-15 | 2006-10-20 | Thomson Licensing Sa | Appareil et procede de gestion des services recus au sein d'un reseau local |
JP4498315B2 (ja) | 2005-07-28 | 2010-07-07 | Hoya株式会社 | 光学ガラスおよび光学素子とその製造方法 |
US7664856B2 (en) | 2005-07-28 | 2010-02-16 | Microsoft Corporation | Dynamically balancing user experiences in a multi-user computing system |
US7688788B2 (en) * | 2005-10-11 | 2010-03-30 | Microsoft Corporation | Congestion level and signal quality based estimator for bit-rate and automated load balancing for WLANS |
FR2895182A1 (fr) | 2005-12-20 | 2007-06-22 | Thomson Licensing Sas | Procede de transmission de services de television numerique, passerelle et reseau correspondants |
US7669222B2 (en) | 2006-01-17 | 2010-02-23 | Microsoft Corporation | Virtual tuner management |
CN101438256B (zh) * | 2006-03-07 | 2011-12-21 | 索尼株式会社 | 信息处理设备、信息通信系统、信息处理方法 |
US7996032B2 (en) * | 2006-03-27 | 2011-08-09 | Qualcomm Incorporated | Power control and resource management in orthogonal wireless systems |
SE530774C2 (sv) * | 2006-12-01 | 2008-09-09 | Teliasonera Ab | System och metod för hantering av bandbredd i ett hemnät för television |
CN100581173C (zh) * | 2006-12-01 | 2010-01-13 | 清华大学 | 一种视频网格自适应负载均衡调度方法 |
JP5503560B2 (ja) * | 2008-02-29 | 2014-05-28 | トムソン ライセンシング | 負荷分散信号分配を行う方法および装置 |
-
2008
- 2008-12-12 JP JP2010548654A patent/JP5503560B2/ja not_active Expired - Fee Related
- 2008-12-12 WO PCT/US2008/013640 patent/WO2009108176A1/en active Application Filing
- 2008-12-12 EP EP08873030A patent/EP2260636A1/en not_active Ceased
- 2008-12-12 KR KR1020107019170A patent/KR101531960B1/ko active IP Right Grant
- 2008-12-12 CN CN201510779348.XA patent/CN105306586A/zh active Pending
- 2008-12-12 CN CN2008801266912A patent/CN101946491A/zh active Pending
- 2008-12-12 BR BRPI0822217-7A patent/BRPI0822217B1/pt not_active IP Right Cessation
- 2008-12-12 US US12/735,933 patent/US9015781B2/en not_active Expired - Fee Related
-
2014
- 2014-03-14 JP JP2014051879A patent/JP5873124B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
BRPI0822217B1 (pt) | 2020-11-10 |
BRPI0822217A2 (pt) | 2015-06-23 |
EP2260636A1 (en) | 2010-12-15 |
US9015781B2 (en) | 2015-04-21 |
WO2009108176A1 (en) | 2009-09-03 |
JP2011519492A (ja) | 2011-07-07 |
KR20100123703A (ko) | 2010-11-24 |
CN105306586A (zh) | 2016-02-03 |
JP5503560B2 (ja) | 2014-05-28 |
JP2014147088A (ja) | 2014-08-14 |
CN101946491A (zh) | 2011-01-12 |
KR101531960B1 (ko) | 2015-06-26 |
US20100333150A1 (en) | 2010-12-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5873124B2 (ja) | 負荷分散信号分配を行う方法および装置 | |
EP1913775B1 (en) | Ip multicast management and service provision system and method | |
US9419862B2 (en) | System and method for discovering and verifying a hybrid fiber-coaxial topology in a cable network environment | |
US8522288B2 (en) | IP broadcasting system and a multicast group management apparatus for the same | |
US10521213B2 (en) | Technique for efficiently upgrading software in a video content network | |
EP2103083A1 (en) | System and method for combining pull and push modes | |
EP3095229B1 (en) | Method and nodes for configuring a communication path for a media service | |
EP3175580B1 (en) | System, gateway and method for an improved quality of service, qos, in a data stream delivery | |
CN104270604A (zh) | 获取ipc的实时视频数据的方法、系统及装置 | |
CN110462600B (zh) | 用于联网媒体分发的系统、方法和设备 | |
WO2009021460A1 (fr) | Procédé de rapport d'un résultat de mise en œuvre de politique, système de communication par réseau et équipement | |
RU2463718C2 (ru) | Механизмы, предназначенные для обнаружения и уменьшения отказов в устройстве шлюза | |
US9813763B2 (en) | Application for in-field discovery, diagnosis and repair of a set-top device | |
KR102486638B1 (ko) | Iptv 서비스의 이상 유무를 판단하는 방법, 네트워크 장비 및 모니터링 서버 | |
KR20090039970A (ko) | Iptv 네트워크 장애 관리 방법 및 시스템 | |
JP2020123831A (ja) | ノード管理システム、ノード管理方法及びプログラム | |
KR100827493B1 (ko) | 애니캐스트 서비스 지원 방법 및 그 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A132 Effective date: 20150210 |
|
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: 20151215 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160114 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5873124 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |