JP2005221657A - 通信端末 - Google Patents

Abstract

【課題】 リッチなプロトコルを実装することなしに、インターネットを介して効率良くＭＩＤＩメッセージ等を授受することができる通信端末を提供する。
【解決手段】 ＭＩＤＩメッセージを伝送するプロトコルとして、インターネットの伝送プロトコルとして広く利用されているＴＣＰ及びＵＤＰを用いる。送信側のプレーヤ端末２００は、伝送すべきＭＩＤＩメッセージについて、絶対に欠落してはいけないシステムエクスクルーシブメッセージと、そうではない他のＭＩＤＩメッセージとに分類する。送信側のプレーヤ端末２００は、システムエクスクルーシブメッセージについては信頼性の高いＴＣＰを用いて伝送する一方、他のＭＩＤＩメッセージについては信頼性の低いＵＤＰを用いて伝送する。
【選択図】 図３

Description

本発明は、通信端末に関し、特にインターネット等の通信ネットワークを介して楽音制御データを授受する通信端末に関する。

図１５は、ＭＩＤＩ（Musical Instrument Digital Interface）規格に準拠した電子楽器や機器（以下、ＭＩＤＩ機器）の接続状態を例示した図である。各ＭＩＤＩ機器は、ＭＩＤＩケーブルによって接続され、一方のＭＩＤＩ機器において生成されたＭＩＤＩメッセージ（楽音制御データ）は、ＭＩＤＩケーブルを介して他方のＭＩＤＩ機器に伝送される。

このように、ＭＩＤＩメッセージは、ＭＩＤＩケーブルを介して授受されるのが一般的であるが、通信ネットワークが発達した近年においては、インターネットを介してＭＩＤＩメッセージを授受し、掛け合い演奏や合奏（セッション）を実現したいという要望が高まっている。

ところが、現状の伝送方式は、ＭＩＤＩメッセージの欠落等について予め想定されていない。従って、伝送誤り等が生じやすいインターネット伝送に現状の伝送方式をそのまま適用したとしても、ＭＩＤＩメッセージの欠落の発生等により演奏を忠実に再現できないといった問題を生ずる。

かかる事情に鑑み、ＩＥＴＦ（Internet Engineering Task Force）において、ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩという規格が策定されつつある（例えば、非特許文献１参照）。このＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩは、インターネット等のパケット通信網を介してＭＩＤＩメッセージを伝送するための規格であり、信頼性が高く、かつ、効率の高いデータ伝送を実現することができるといった特徴を有している。

［online］［平成１６年２月２日検索］インターネット＜URL:http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-08.txt＞

しかしながら、このＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩ規格に準拠した伝送を行うためには、インターネット通信に関わるプロトコル群の中核をなすＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）を実装するだけでなく、ＲＴＰ（Real-Time Transport Protocol）、ＲＴＣＰ（Real-Time Control Protocol）、ＳＤＰ（Session Description Protocol）といった資源（ＣＰＵ資源やメモリ資源等）を多く使用しなければならないプロトコル（以下、「リッチなプロトコル」と総称する）をＭＩＤＩ機器に実装する必要がある。ところが、電子楽器等のプラットフォームにおいては、ＲＴＰ、ＲＴＣＰ、ＳＤＰといったプロトコルを実装できるほどＣＰＵ資源・メモリ資源等に余裕がないのが現状である。

本発明は、以上説明した事情を鑑みてなされたものであり、ＲＴＰ、ＲＴＣＰ、ＳＤＰといったリッチなプロトコルを実装することなしに、インターネットを介して効率良くＭＩＤＩメッセージ等を授受することができる通信端末を提供することを目的とする。

上述した問題を解決するため、本発明に係る通信端末は、コネクション型のプロトコルとコネクションレス型のプロトコルとを実装した通信端末であって、楽音制御データを入力する入力手段と、入力される楽音制御データを２系統に分類し、各系に属する楽音制御データをそれぞれパケット化して楽音制御パケットを生成するパケット生成手段と、生成した一方の系に属する前記楽音制御パケットについては、前記コネクション型のプロトコルを利用して相手端末へ送信する一方、分類した他方の系に属する前記楽音制御パケットについては、前記コネクションレス型のプロトコルを利用して前記相手端末へ送信する送信手段とを具備することを特徴とする。

かかる構成によれば、信頼性の高いコネクション型のプロトコル及び信頼性の低いコネクションレス型のプロトコルの両プロトコルを用いて楽音制御データ（ＭＩＤＩメッセージ等）を伝送する。ここで、信頼性の高いコネクション型のプロトコルを用いて伝送する楽音制御データ（例えばシステムエクスクルーシブメッセージ）と信頼性の低いコネクションレス型のプロトコルを用いて伝送する楽音制御データ（例えば他のＭＩＤＩメッセージ）を適宜設定することで、相手端末との間で効率よくＭＩＤＩメッセージ等を授受することが可能となる。

ここで、上記構成にあっては、前記コネクション型のプロトコル若しくは前記コネクションレス型のプロトコルを利用して送信される全ての楽音制御パケットに対し、送信順をあらわすシーケンス番号を付加する第１の付加手段をさらに具備する態様が好ましい。ここで、前記第１の付加手段は、前記コネクションレス型のプロトコルを利用して送信される各楽音制御パケットについては、当該パケットを識別するためのシーケンス番号を付加するほか、前記コネクション型のプロトコルを利用して既に送信された直近の楽音制御パケットに付加されているシーケンス番号をさらに付加する態様がより好ましい。

また、上記構成にあっては、前記コネクションレス型のプロトコルを利用して送信される各楽音制御パケットに対し、当該時点までに該コネクションレス型のプロトコルを利用して送信された楽音制御パケットの履歴をあらわす履歴情報を付加する第２の付加手段をさらに具備する態様が好ましい。

また、上記構成にあっては、コマンド内容を含まない空パケットを生成する空パケット生成手段と、前記コネクションレス型のプロトコルを利用して送信される前記各楽音制御パケットの生成タイミングを検知する検知手段とをさらに具備し、前記送信手段は、予め設定された閾値時間内に前記楽音制御パケットの生成タイミングが検知されなかったとき、前記空パケット生成手段によって生成される空パケットを前記コネクションレス型のプロトコルを利用して前記相手端末へ送信する態様が好ましい。

また、上記構成にあっては、前記パケット生成手段は、入力される楽音制御データのうち、設定条件に合致する楽音制御データについてパケット化することにより、前記楽音制御パケットを生成する態様が好ましい。

以上説明したように、本発明によれば、ＲＴＰやＳＤＰといったリッチなプロトコルを用いることなく、インターネットを介して効率良くＭＩＤＩメッセージ等を授受することが可能となる。

以下、様々な場所に点在する複数のユーザがインターネットを介してＭＩＤＩメッセージを授受することにより、リアルタイムなセッションを可能とするシステム（以下、iSessionシステムという）について説明する。

Ａ．本実施形態
図１は、本実施形態に係るiSessionシステム１００の構成を示す図である。
iSessionシステム１００は、インターネット３５０を介して接続された複数のプレーヤ端末２００−ｋ（１≦ｋ≦ｎ）と、各プレーヤ端末２００−ｋに接続された電子楽器３００−ｋと、セッション管理サーバ４００とによって構成されている。なお、プレーヤ端末２００−ｋ及び電子楽器３００−ｋについて、特に区別する必要がない場合には単にプレーヤ端末２００及び電子楽器３００と呼ぶ。

セッション管理サーバ４００は、プレーヤ端末２００によって実現されるセッションを中枢的に管理する役割等を担っている。電子楽器３００は、ユーザによる演奏操作に従って様々なＭＩＤＩメッセージを生成し、生成したＭＩＤＩメッセージを接続先のプレーヤ端末２００に供給する。
プレーヤ端末（通信端末）２００は、電子楽器３００から供給されるＭＩＤＩメッセージをパケット化してＭＩＤＩパケット（楽音制御パケット）を生成し、これをセッションに参加している全てのプレーヤ端末２００に送信する一方、他のプレーヤ端末２００から送信されるＭＩＤＩパケットを受信・再生する。なお、本実施形態では、電子楽器３００とプレーヤ端末２００とが別体の場合を想定するが、例えば電子楽器３００にプレーヤ端末２００の機能を実装し、電子楽器３００とプレーヤ端末２００とを一体構成にしても良い。

＜iSessionシステム１００の第１の特徴＞
図２は、iSessionシステム１００で用いられる伝送プロトコルを説明するための図である。本実施形態に係るiSessionシステム１００は、ＲＴＰやＳＤＰといったリッチなプロトコルを用いることなく、インターネット３５０の伝送プロトコルとして広く利用されているＴＣＰ及びＵＤＰを用いてＭＩＤＩパケットを伝送する。ＴＣＰ及びＵＤＰは、いずれもＴＣＰ／ＩＰプロトコル群におけるトランスポート層に位置するプロトコルである（図２参照）。ここで、ＴＣＰは、データを確実に届けることを目的とした信頼性の高いプロトコルであり、シーケンス制御などを行うことからコネクション型のプロトコルと呼ばれる。一方、ＵＤＰは、伝送路におけるパケットの欠落等に対して何ら対応がない信頼性の低いプロトコルであり、ＴＣＰのようなシーケンス制御を行わないことからコネクションレス型のプロトコルと呼ばれる。

本実施形態では、これら信頼性の高いＴＣＰと信頼性の低いＵＤＰの２系統の伝送路を用いてＭＩＤＩメッセージを伝送する。詳述すると、プレーヤ端末（送信手段）２００は、まず、伝送すべきＭＩＤＩメッセージについて、絶対に欠落してはいけないＭＩＤＩメッセージ（本実施形態ではシステムエクスクルーシブメッセージ）と、そうではない他のＭＩＤＩメッセージとに分類する。かかる分類を行うと、プレーヤ端末（送信手段）２００は、システムエクスクルーシブメッセージについては信頼性の高いＴＣＰを用いて伝送する一方、他のＭＩＤＩメッセージについては信頼性の低いＵＤＰを用いて伝送する。

なお、本実施形態では、様々な種類のＭＩＤＩメッセージのうちの１種類のＭＩＤＩメッセージ（すなわち、システムエクスクルーシブメッセージ）についてのみ、ＴＣＰを用いて伝送する場合を例示したが、ＴＣＰを用いて伝送するＭＩＤＩメッセージの種類や数等については、iSessionシステム１００の運用等に応じて適宜変更可能である。また、以下の説明では、ＴＣＰを用いた伝送路をＴＣＰストリームと呼び、ＴＣＰストリームを流れるパケット化されたＭＩＤＩメッセージをＴＣＰパケットと呼ぶ（図３参照）。ＵＤＰも同様、ＵＤＰを用いた伝送路をＵＤＰストリームと呼び、ＵＤＰストリームを流れるパケット化されたＭＩＤＩメッセージをＵＤＰパケットと呼ぶ（図３参照）。

＜iSessionシステム１００の第２の特徴＞
図４は、ＴＣＰストリーム及びＵＤＰストリームを流れるＴＣＰパケット及びＵＤＰパケットを例示した図である。
本実施形態では、上記の如くＴＣＰストリーム及びＵＤＰストリーム（以下、これらをデュアルストリームと総称）を利用してパケット化したＭＩＤＩメッセージを伝送する。このため、受信側のプレーヤ端末２００においてＭＩＤＩメッセージを正しく再生するためには、各ストリームを流れてくるパケットを正しい順番（すなわち送信された順番）で処理する必要がある。これを実現するために、本実施形態では、図４に示すようにＴＣＰストリーム及びＵＤＰストリームを流れる全てのパケットについて、送信順をあらわすユニークなシーケンス番号を付加する。受信側のプレーヤ端末２００は、シーケンス番号通りに各パケットを処理することで、同期をとることができる。ただし、ＵＤＰストリームは、前述したように信頼性の低い伝送路であるため、ＵＤＰパケットが欠落したり、ＵＤＰパケットの順番が入れ違う等（後に送信したＵＤＰパケットが、その前に送信したＵＤＰパケットよりも先に受信側のプレーヤ端末２００に届く等）の事態が生じうる。以下に示す第３の特徴は、このような事態に対処するものである。

＜iSessionシステム１００の第３の特徴＞
図５は、ＴＣＰストリームを流れるＴＣＰパケットの構成を示す図であり、図６は、ＵＤＰストリームを流れるＵＤＰパケットの構成を示す図である。
ＴＣＰパケットは、タイムスタンプ、シーケンスナンバ、コマンドセクションを具備する一方、ＵＤＰパケットは、タイムスタンプ、第１シーケンスナンバ、第２シーケンスナンバ、コマンドセクション、ジャーナルセクションを具備している。

ＴＣＰパケット及びＵＤＰパケットのタイムスタンプには、それぞれiSessionタイマ（図示略）のタイマ値がそのまま記述される。
ＴＣＰパケットのシーケンスナンバには、当該ＴＣＰパケットの送信順をあらわすユニークなシーケンス番号が記述される。ＵＤＰパケットの第１シーケンスナンバも同様、当該ＵＤＰパケットの送信順をあらわすユニークなシーケンス番号が記述される。これに対し、ＵＤＰパケットの第２シーケンスナンバには、既に送信された直近のＴＣＰパケットのシーケンス番号が記述される。なお、直近のＴＣＰパケットが存在しない場合（未だＴＣＰパケットが１つも送信されていない場合等）には、ＵＤＰパケットの第２シーケンスナンバにシーケンス番号「０」が記述される。かかる構成を採用することで、ＵＤＰパケットがロスしたときのリカバリを適切に行うことが可能となるが、この点については後述する。

ＴＣＰパケットのコマンドセクションには、システムエクスクルーシブメッセージをあらわすコマンド内容が記述され、ＵＤＰパケットのコマンドセクションには、システムエクスクルーシブメッセージ以外の他のＭＩＤＩメッセージをあらわすコマンド内容が記述される。
また、ＵＤＰパケットには、ジャーナルセクションが設けられ（図６参照）、このジャーナルセクションには、パケットロス等からのリカバリに必要な情報であって、当該時点までに伝送されたＵＤＰパケット（コマンド内容等）の履歴をあらわす履歴情報（以下、ジャーナルという）が記述される。このジャーナルは、上述したＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩにおいて導入された概念であり、ＵＤＰパケットがロスしたときのリカバリを行う際等に利用される。

ただし、ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩとiSessionシステム１００とは、パケットの伝送方式が異なるため、ジャーナルを利用したリカバリの方法も異なる。詳述すると、ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ ＭＩＤＩは、ＵＤＰストリーム（すなわちシングルストリーム）のみを利用してパケット伝送を行うのに対し、iSessionシステム１００は、ＵＤＰストリーム及びＴＣＰストリーム（デュアルストリーム）を利用してパケット伝送を行うため、両者におけるリカバリ方法もそれぞれ異なる。しかしながら、各リカバリ方法の基本的な考え方は共通するため、まず、シングルストリームにおけるリカバリ方法について説明し、その後にデュアルストリームにおけるリカバリ方法について説明する。

（シングルストリームにおけるリカバリ方法）
図７は、シングルストリームにおけるリカバリ方法を説明するための図である。 ＵＤＰストリームを流れる各ＵＤＰパケットには、送信順をあらわすシーケンス番号が付加されるほか、セッション開始から現時点までに伝送されたＵＤＰパケットの履歴をあらわすジャーナルが付加される。ここで、例えば図７のＡに示すように、全てのＵＤＰパケットが正常な状態でＵＤＰストリームを流れている場合、受信側のプレーヤ端末２００は、各パケットに付加されているシーケンス番号を参照することで全てのＵＤＰパケットを正常に処理することができる。

一方、図７のＢに示すように一部のＵＤＰパケット（シーケンス番号「３」）が欠落すると、受信側のプレーヤ端末２００は、その後に受け取るＵＤＰパケット（シーケンス番号「４」）のジャーナルを参照することで、欠落したＵＤＰパケットのリカバリを行う。具体的には、シーケンス番号「３」のＵＤＰパケットが伝送途中で欠落すると、受信側のプレーヤ端末２００は、シーケンス番号「２」のＵＤＰパケットを受け取った後に、シーケンス番号「４」のＵＤＰパケットを受け取ることになる（図７のＢ参照）。受信側のプレーヤ端末２００は、受け取ったＵＤＰパケットのシーケンス番号が「２」から「４」に飛んだことから、シーケンス番号「３」のＵＤＰパケットが欠落したと判断する。受信側のプレーヤ端末２００は、このような判断に基づき、シーケンス番号「４」のＵＤＰパケットに付加されているジャーナルを参照し、欠落したシーケンス番号「３」のＵＤＰパケットのリカバリ処理を行う。

例えば、欠落したシーケンス番号「３」のＵＤＰパケットに「発音中の楽音（Ｃ４等）を消音せよ」といったコマンドが含まれていれば、シーケンス番号「４」のＵＤＰパケットのジャーナルには、シーケンス番号「３」のＵＤＰパケットのコマンド内容が含まれていることになる（上記ジャーナルの説明参照）。受信側のプレーヤ端末２００は、シーケンス番号「４」のＵＤＰパケットのジャーナルを解析することで、シーケンス番号「３」のＵＤＰパケットに「発音中の楽音（Ｃ４等）を消音せよ」といったコマンドが含まれていると判断すると、このコマンド内容に基づき発音中の楽音を消音する。以上説明したリカバリ処理は、ＵＤＰパケットが欠落したときのみならず、ＵＤＰパケットの順番が入れ替わった場合も同様にして行われる。

例えば、図７のＣに示すように、伝送途中においてシーケンス番号「３」のＵＤＰパケットとシーケンス番号「２」のＵＤＰパケットの順番が入れ替わった場合、受信側のプレーヤ端末２００は、シーケンス番号「３」のＵＤＰパケットを受信した段階でシーケンス番号「２」のＵＤＰパケットが欠落したと判断する。かかる判断に基づき、受信側のプレーヤ端末２００は、上記と同様のリカバリ処理を行う。このように、シーケンス番号「２」のＵＤＰパケットについては、シーケンス番号「３」のＵＤＰパケットのジャーナルを用いてリカバリされるため、その後にシーケンス番号「２」のＵＤＰパケットが到着したとしても、シーケンス番号「２」のＵＤＰパケットは捨てられることになる（図７のＣ参照）。

なお、ＵＤＰパケットに付加するジャーナルがその前のＵＤＰパケットに付加したジャーナルと同じ場合（すなわち、処理すべきコマンド内容に変更がない場合）には、このＵＤＰパケットが欠落したとしてもリカバリ処理は必要ない。かかる場合には、ジャーナルをＵＤＰパケットに付加する代わりに、リカバリ処理が不要である旨の情報をＵＤＰパケットに付加して対処すれば良い。

（デュアルストリームにおけるリカバリ方法）
図８及び図９は、デュアルストリームにおけるリカバリ方法を説明するための図であり、前掲図７に対応する図である。
ＵＤＰストリームを流れる各ＵＤＰパケットには、上述したシーケンス番号やジャーナルが付加されるほか、直近のＴＣＰパケットのシーケンス番号が付加される（図８及び図９に示す括弧書き参照）。例えば、図８のＡに示すように、シーケンス番号「３」、「４」の各ＵＤＰパケットには、直近のＴＣＰパケットのシーケンス番号「２」がさらに付加される一方、シーケンス番号「６」が付加されたＵＤＰパケットには、直近のＴＣＰパケットのシーケンス番号「５」がさらに付加される。ただし、直近のＴＣＰパケットが存在しないＵＤＰパケット（シーケンス番号「１」が付加されたＵＤＰパケット）については、直近のＴＣＰパケットが存在しないことを明らかにするため、シーケンス番号「０」がさらに付加される。このデュアルストリーム環境下において全てのＵＤＰパケットが正常な状態でＵＤＰストリームを流れている場合には、上記シングルストリーム環境下における場合と同様、受信側のプレーヤ端末２００は、各パケットに付加されているシーケンス番号を参照することで全てのＵＤＰパケットを正常に処理することができる。

また、図８のＢに示すように一部のＵＤＰパケットが欠落した場合も、上記シングルストリーム環境下における場合と同様、受信側のプレーヤ端末２００は、その後に受け取るＵＤＰパケットのジャーナルを参照することで、欠落したＵＤＰパケットのリカバリを行う。
詳述すると、図８のＢに示すようにシーケンス番号「４」のＵＤＰパケットが欠落した場合、受信側のプレーヤ端末２００は、シーケンス番号「３」のＵＤＰパケットを受け取った後に、シーケンス番号「６」のＵＤＰパケットを受け取ることになる。受信側のプレーヤ端末２００は、受け取ったＵＤＰパケットのシーケンス番号及びＴＣＰパケットのシーケンス番号に基づいて、シーケンス番号「４」のＵＤＰパケットが欠落したと判断すると、シーケンス番号「６」のＵＤＰパケットに付加されているジャーナル（本実施例ではシーケンス番号「１」、「３」、「４」のＵＤＰパケットの履歴をあらわすジャーナル）を参照し、欠落したシーケンス番号「４」のＵＤＰパケットのリカバリを行う。一方、パケットの順番が入れ替わった場合のリカバリ処理は、上記シングルストリーム環境下における場合と異なり、次のようにして行う。

（パターン１；ＴＣＰパケットの到達が速まった場合）
図９のＣに示すように、パケット順番の入れ違い発生によりＴＣＰパケット（シーケンス番号；「２」）→ＵＤＰパケット（シーケンス番号；「１」）の順番で受信側のプレーヤ端末２００に到達した場合、先に到達したＴＣＰパケットについては到達した時点で直ちに処理される一方、遅れて到達したＵＤＰパケット（シーケンス番号；「１」）については欠落したものとして扱われる。欠落したものとして取り扱われたＵＤＰパケットのリカバリは、その次に到達するＵＤＰパケット（シーケンス番号；「３」）のジャーナルを用いて行われる。

（パターン２；ＴＣＰパケットの到達が遅れた場合）
図９のＤに示すように、パケット順番の入れ違い発生によりＵＤＰパケット（シーケンス番号；「３」）→ＴＣＰパケット（シーケンス番号；「２」）の順番で受信側のプレーヤ端末２００に到達した場合、先に到達したＵＤＰパケットについては、バッファ等に一時保管され、遅れているＴＣＰパケットが到着するまで処理は開始されない。上述したように、各ＵＤＰパケットには、ＴＣＰパケットの到着が遅れているか否かを判断するために、当該パケットよりも前に処理されるべき直近のＴＣＰパケットのシーケンス番号が付加されている。受信側のプレーヤ端末２００は、該ＵＤＰパケットに付加されている直近のＴＣＰパケットのシーケンス番号を参照することで、当該ＵＤＰパケットの処理を遅らせるか否かを判断し、直近のＴＣＰパケットが届いていない場合には、遅れているＴＣＰパケットが到着するまで該ＵＤＰパケットの処理を遅らせる。以上のようにして、デュアルストリーム環境下におけるリカバリ方法が実現される。

＜iSessionシステム１００の第４の特徴＞
また、iSessionシステム１００は、送信側のプレーヤ端末２００と受信側のプレーヤ端末２００との間の通信が切れたか否かを検出するための構成にも特徴がある。
詳述すると、通信が行われている間は、最低でも１秒間に１つ、送信側のプレーヤ端末２００は受信側のプレーヤ端末２００にパケットを送信する。送信側のプレーヤ端末（検知手段）２００は、このパケットの生成タイミングを常に検知している。送信側のプレーヤ端末（空パケット生成手段）２００は、予め設定された閾値時間内（例えば１秒間内）にパケットが生成送信されなかったことを検知すると、コマンドセクションが空のパケット（いいかえれば、コマンド内容を含まない空のパケット）を生成し、これを受信側のプレーヤ端末２００に送信する。ただし、このパケットにおけるジャーナルセクションは空ではなく、当該時点までに送信されたＵＤＰパケットのジャーナルが記述される。

一方、受信側のプレーヤ端末２００は、所定時間（例えば３秒間）、ＵＤＰパケットを受け取らないと、送信側のプレーヤ端末２００との間の通信が切れたとみなす。
以上説明した構成を採用することで、従来の如く送信側の端末からアクティブセンスメッセージ（ＭＩＤＩケーブルが断線した場合などに、受信側の端末において音が鳴りっぱなしになってしまうことを防ぐために送信される情報）を送信することなく、受信側の端末において上記通信が切れたか否かを判断することができる。このように、送信側の端末においてアクティブセンスメッセージを除去することで、ＴＣＰ／ＩＰ通信のバンド幅を有効に使用することができる。なお、上記例において定義した時間等（例えば、送信側のプレーヤ端末２００からＵＤＰパケットが送信される最低時間間隔等）については、iSessionシステム１００の設計等に応じて適宜変更可能である。
以下、かかるiSessionシステム１００を実現する各プレーヤ端末２００の動作について、図１０〜図１４等を参照して説明する。

＜パケット送信動作＞
図１０は、各プレーヤ端末２００のＭＩＤＩ送信部によって実行されるパケット送信処理を示す図である。ＭＩＤＩ送信部は、接続された電子楽器等から供給されるＭＩＤＩメッセージをパケット化し、これをセッションに参加している全てのプレーヤ端末２００へ送信する機能を提供する。このＭＩＤＩ送信部は、各プレーヤ端末２００に搭載されているハードウェア資源（通信装置、ＣＰＵ、メモリ等）とメモリに格納されたソフトウェアとが協働して動作することにより実現される。

ＭＩＤＩ送信部（入力手段）は、ＭＩＤＩドライバ（図示略）を介して電子楽器から様々なＭＩＤＩメッセージを受け取ると、受け取ったＭＩＤＩメッセージの中からＴＣＰストリーム及びＵＤＰストリームのいずれにものせないＭＩＤＩメッセージ、すなわちデュアルストリームにのせないＭＩＤＩメッセージを除去する（ステップＳ１→ステップＳ２）。なお、除去するＭＩＤＩメッセージとしては、例えばタイミングクロック、アクティブセンシングメッセージ、オールノートオフメッセージ、ランニングステータスを利用したメッセージ等が挙げられるが、どのようなＭＩＤＩメッセージを除去してどのようなＭＩＤＩメッセージをパケット化するか（すなわち、設定条件）については、iSessionシステム１００の運用等に応じて適宜設定・変更可能である。

ＭＩＤＩ送信部は、上記の如くデュアルストリームにのせないＭＩＤＩメッセージを除去してデュアルストリームにのせるＭＩＤＩメッセージ（すなわち、設定条件に合致するＭＩＤＩメッセージ）のみを抽出すると、図示せぬ指定手段から与えられるポート分割指示に従って、各ＭＩＤＩメッセージを各ポートに振り分ける（ステップＳ３）。なお、本実施形態においては、使用するポートが複数定義されているマルチポート（図１１参照）を想定するが、使用するポートが１つのシングルポート（図１２参照）についても同様に適用可能である。

ＭＩＤＩ送信部は、かかる振り分けを行うと、iSessionタイマを参照して各ポートに振り分けたＭＩＤＩメッセージにかりのタイムスタンプを付加し、これらをポート毎に設けられた各ＭＩＤＩメッセージバッファ（図示略）に順次格納する（ステップＳ４→ステップＳ５）。そして、ＭＩＤＩ送信部は、ＭＩＤＩメッセージバッファから１パケット分のＭＩＤＩメッセージをまとめて取得する（ステップＳ６）。ただし、ＭＩＤＩメッセージのうち、システムエクスクルーシブメッセージについては、他のＭＩＤＩメッセージと同時に送信することができないため、システムエクスクルーシブメッセージと他のＭＩＤＩメッセージとは別にまとめて取得する。なお、１パケットに詰め込むＭＩＤＩメッセージのデータ量については、iSessionシステム１００の運用等に応じて適宜設定される。

ここで、取得したＭＩＤＩメッセージがシステムエクスクルーシブメッセージ以外のＭＩＤＩメッセージ（以下、他のＭＩＤＩメッセージ）である場合、ＭＩＤＩ送信部（パケット生成手段）は、ＵＤＰストリームにのせて伝送すべきと判断し、取得した他のＭＩＤＩメッセージをパケット化してＵＤＰパケットを生成する（ステップＳ７→ステップＳ８）。ＭＩＤＩ送信部（第１の付加手段、第２の付加手段）は、このように生成したＵＤＰパケットに対し、当該ＵＤＰパケットの送信順をあらわすシーケンス番号や、直近のＴＣＰパケットに付加されているシーケンス番号、さらには、これまでに送信されたＵＤＰパケットの履歴をあらわすジャーナルを付加する（ステップＳ９→ステップＳ１０）。そして、ＭＩＤＩ送信部（送信手段）は、このようにシーケンス番号、ジャーナルを付加したＵＤＰパケットをセッションに参加している全てのプレーヤ端末２００に送信し（ステップＳ１１）、処理を終了する。

一方、取得したＭＩＤＩメッセージがシステムエクスクルーシブメッセージである場合、ＭＩＤＩ送信部（パケット生成手段）は、ＴＣＰストリームにのせて伝送すべきと判断し、取得したシステムエクスクルーシブメッセージを１パケットに収まるように当該メッセージを分割し、パケット化する（ステップＳ７→ステップＳ１２→ステップＳ１３）。ＭＩＤＩ送信部（送信手段）は、このようにしてシステムエクスクルーシブメッセージを含むＴＣＰパケットを生成すると、当該ＴＣＰパケットの送信順をあらわすシーケンス番号を付加し（ステップＳ１４）、これをセッションに参加している全てのプレーヤ端末２００に送信し（ステップＳ１１）、処理を終了する。

＜パケット受信動作＞
図１３及び図１４は、各プレーヤ端末２００のＭＩＤＩ受信部によって実行されるパケット受信処理を示す図である。ここで、ＭＩＤＩ受信部は、他のプレーヤ端末２００から送信されるパケットをＭＩＤＩメッセージに復元するとともに、復元した各ＭＩＤＩメッセージに示されるコマンドを適切なタイミングでマージする機能を提供する。このＭＩＤＩ受信部もＭＩＤＩ送信部と同様、各プレーヤ端末２００に搭載されているハードウェア資源（通信装置、ＣＰＵ、メモリ等）とメモリに格納されたソフトウェアとが協働して動作することにより実現される。

ＭＩＤＩ受信部（受信手段）は、他のプレーヤ端末２００からインターネット３５０等を介してパケットを受信すると、当該パケットがＵＤＰパケットであるか、あるいはＴＣＰパケットであるかを判断する（ステップＳａ１→ステップＳａ２）。ＭＩＤＩ受信部は、ＵＤＰパケットであると判断すると、このＵＤＰパケットをいったんバッファに格納する（ステップＳａ２→ステップＳａ３）。このように、受信したＵＤＰパケットをいったんバッファに格納するのは、先に届くべきＴＣＰパケットが届かない場合等には、このＴＣＰパケットが届くまで当該ＵＤＰパケットの処理を遅らせなければならないからである。

ＭＩＤＩ受信部（リカバリ手段）は、ＵＤＰパケットに付加されているシーケンス番号やこれまでに受信したＴＣＰパケットに付加されているシーケンス番号等をチェックするとともに、当該ＵＤＰパケットに付加されているジャーナル等を解析する（ステップＳａ４）。ＭＩＤＩ受信部（リカバリ手段）は、解析結果に基づきリカバリ処理が必要であると判断すると（ステップＳａ５；Ｙｅｓ）、欠落したＵＤＰパケットをジャーナルを用いて新たに生成する等のリカバリ処理を行う（ステップＳａ６）。なお、このリカバリ処理の詳細は、上述したため割愛する。

ＭＩＤＩ受信部は、リカバリ処理を行うと、該リカバリ処理後のＵＤＰパケットに含まれるＭＩＤＩメッセージ（ただし、この場合はシステムエクスクルーシブメッセージを除く他のＭＩＤＩメッセージ）に実行すべき時刻のタイムスタンプを付加し、これを図示せぬＭＩＤＩコマンドキューに格納する（ステップＳａ７→ステップＳａ８）。

一方、ＭＩＤＩ受信部は、他のプレーヤ端末２００から受信したパケットがＴＣＰパケットであると判断すると、このＴＣＰパケットに含まれるシステムエクスクルーシブメッセージが分割されているか否かを判断する（ステップＳａ２→ステップＳａ１２）。ＭＩＤＩ受信部は、該メッセージが分割されていると判断すると、分割された各システムエクスクルーシブメッセージを用いることにより、分割前のシステムエクスクルーシブメッセージを復元する（ステップＳａ１３）。そして、ＭＩＤＩ受信部は、復元したシステムエクスクルーシブメッセージに実行すべき時刻のタイムスタンプを付加し、これを専用のシステムエクスクルーシブバッファ（図示略）に格納する（ステップＳａ１４→ステップＳａ１５）。

ＭＩＤＩ受信部は、受信したＭＩＤＩメッセージをＭＩＤＩコマンドキュー若しくはシステムエクスクルーシブバッファに格納すると、これらＭＩＤＩコマンドキュー若しくはシステムエクスクルーシブバッファに格納されている全ＭＩＤＩメッセージの中から最もはやく処理すべきＭＩＤＩメッセージを選択し、これを取り出す（ステップＳａ９）。そして、ＭＩＤＩ受信部は、取り出したＭＩＤＩメッセージに付加されているタイムスタンプとiSessionタイマ（図示略）に示される時刻とを比較することにより、当該イベントの処理タイミングが到来したか否かを判断する（ステップＳａ１０）。ＭＩＤＩ受信部は、ステップＳａ１０を繰り返し実行している間に処理タイミングが到来したと判断すると（ステップＳａ１０；Ｙｅｓ）、適切なＭＩＤＩマージ処理を行い（ステップＳａ１１）、当該イベントに示されるＭＩＤＩコマンドをＭＩＤＩドライバに送って処理を終了する。かかるＭＩＤＩコマンドは、ＭＩＤＩドライバから音源（図示略）に転送され、該ＭＩＤＩコマンドに基づく楽音が発生される。

以上説明したように、本実施形態によれば、セッションに参加する各プレーヤ端末は、ＲＴＰ、ＲＴＣＰ、ＳＤＰといったリッチなプロトコルを実装することなく、既存のＴＣＰ、ＵＤＰを用いて効率よくＭＩＤＩパケットを授受することが可能となる。
また、ＴＣＰパケットやＵＤＰパケットに付与するシーケンスナンバやジャーナルを上記の如く設定することにより、デュアルストリームに対応したパケットロスからのリカバリ等を単純な方法によって実現することができる。

なお、以上説明した本実施形態に係るプレーヤ端末２００の諸機能は、ＲＯＭ等に格納されたプログラムによって実現されるため、かかるプログラムを記録媒体（ＣＤ−ＲＯＭ等）に記録して頒布したり、通信ネットワーク（インターネット等）を介して頒布しても良い。もちろん、上記諸機能を実現するＣＰＵ、ＲＯＭ等を組み込んだ専用装置として構成することも可能である。

本実施形態に係るiSessionシステムの構成を示す図である。 同実施形態に係る伝送プロトコルを説明するための図である。 同実施形態に係るＴＣＰストリーム及びＵＤＰストリームを流れるＴＣＰパケット及びＵＤＰパケットを例示した図である。 同実施形態に係るＴＣＰストリーム及びＵＤＰストリームを流れるＴＣＰパケット及びＵＤＰパケットを例示した図である。 同実施形態に係るＴＣＰパケットの構成を示す図である。 同実施形態に係るＵＤＰパケットの構成を示す図である。 同実施形態に係るシングルストリームにおけるリカバリ方法を説明するための図である。 同実施形態に係るデュアルストリームにおけるリカバリ方法を説明するための図である。 同実施形態に係るデュアルストリームにおけるリカバリ方法を説明するための図である。 同実施形態に係るパケット送信処理を示すフローチャートである。 同実施形態に係るマルチポートの概念をあらわす図である。 同実施形態に係るシングルポートの概念をあらわす図である。 同実施形態に係るパケット受信処理を示すフローチャートである。 同実施形態に係るパケット受信処理を示すフローチャートである。 ＭＩＤＩ機器の接続状態を例示した図である。

符号の説明

１００・・・iSessionシステム、２００・・・プレーヤ端末、３００・・・電子楽器、３５０・・・インターネット、４００・・・セッション管理サーバ。

Claims (8)

1. コネクション型のプロトコルとコネクションレス型のプロトコルとを実装した通信端末であって、
   楽音制御データを入力する入力手段と、
   入力される楽音制御データを２系統に分類し、各系に属する楽音制御データをそれぞれパケット化して楽音制御パケットを生成するパケット生成手段と、
   生成した一方の系に属する前記楽音制御パケットについては、前記コネクション型のプロトコルを利用して相手端末へ送信する一方、分類した他方の系に属する前記楽音制御パケットについては、前記コネクションレス型のプロトコルを利用して前記相手端末へ送信する送信手段と
   を具備することを特徴とする通信端末。
2. 前記コネクション型のプロトコル若しくは前記コネクションレス型のプロトコルを利用して送信される全ての楽音制御パケットに対し、送信順をあらわすシーケンス番号を付加する第１の付加手段をさらに具備することを特徴とする請求項１に記載の通信端末。
3. 前記第１の付加手段は、前記コネクションレス型のプロトコルを利用して送信される各楽音制御パケットについては、当該パケットを識別するためのシーケンス番号を付加するほか、前記コネクション型のプロトコルを利用して既に送信された直近の楽音制御パケットに付加されているシーケンス番号をさらに付加することを特徴とする請求項２に記載の通信端末。
4. 前記コネクションレス型のプロトコルを利用して送信される各楽音制御パケットに対し、当該時点までに該コネクションレス型のプロトコルを利用して送信された楽音制御パケットの履歴をあらわす履歴情報を付加する第２の付加手段をさらに具備することを特徴とする請求項１〜３のいずれか１の請求項に記載の通信端末。
5. コマンド内容を含まない空パケットを生成する空パケット生成手段と、
   前記コネクションレス型のプロトコルを利用して送信される前記各楽音制御パケットの生成タイミングを検知する検知手段とをさらに具備し、
   前記送信手段は、予め設定された閾値時間内に前記楽音制御パケットの生成タイミングが検知されなかったとき、前記空パケット生成手段によって生成される空パケットを前記コネクションレス型のプロトコルを利用して前記相手端末へ送信することを特徴とする請求項１〜４のいずれか１の請求項に記載の通信端末。
6. 前記パケット生成手段は、入力される楽音制御データのうち、設定条件に合致する楽音制御データについてパケット化することにより、前記楽音制御パケットを生成することを特徴とする請求項１〜５のいずれか１の請求項に記載の通信端末。
7. 前記コネクション型のプロトコルは、トランスポート層に位置するＴＣＰであり、前記コネクションレス型のプロトコルは、前記トランスポート層に位置するＵＤＰであり、前記楽音制御データは、ＭＩＤＩメッセージであり、前記各系にに属する楽音制御データは、それぞれシステムエクスクルーシブメッセージと他のＭＩＤＩメッセージであり、前記送信手段は、前記システムエクスクルーシブメッセージをパケット化した楽音制御パケットについては、前記ＴＣＰを利用して相手端末へ送信する一方、前記他のＭＩＤＩメッセージをパケット化した楽音制御パケットについては、前記ＵＤＰを利用して前記相手端末へ送信することを特徴とする請求項１〜６のいずれか１の請求項に記載の通信端末。
8. コネクション型のプロトコルとコネクションレス型のプロトコルとを実装した通信端末であって、
   相手端末が前記コネクション型のプロトコルを利用して送信した楽音制御パケット若しくは前記コネクションレス型のプロトコルを利用して送信した楽音制御パケットを受信する受信手段と、
   前記各プロトコルを利用して送信された全楽音制御パケットに付加されている送信順をあらわすシーケンス番号と、前記コネクションレス型のプロトコルを利用して送信された楽音制御パケットに付加されている履歴情報とに基づいて、該コネクションレス型のプロトコルを利用して送信された楽音制御パケットのリカバリを行うリカバリ手段と
   を具備することを特徴とする通信端末。

Images