JP2017092802A - 会議通話システム及びそれに用いられるバックエンドシステム - Google Patents

Abstract

【課題】通信イベント実施にあたり、一時的にシステム構築することができ、また、多様な会議通信を可能にする会議通話システムを提供するものである。
【解決手段】複数の利用者端末１０と、複数の利用者端末が通信ネットワーク２００を介して接続されるバックエンドシステム１００とを有し、バックエンドシステム１００は、複数の中継部（rly）と、映像及び音声それぞれのミキシングデータを生成する複数のミキシング部（mix）と、複数の利用者端末１０のそれぞれに複数のミキシング部（rly）のいずれかを対応づけ、複数の利用者端末１０からの映像データまたは音声データを複数の中継部（rly）を介して複数のミキシング部（mix）に提供し、各ミキシング部（mix）にて生成される映像または音声のミキシングデータを一または複数の中継部（rly）を介して対応する利用者端末１０に向けて配信するよう制御する制御部（cfg-3）とを有する構成となる。
【選択図】図２

Description

本発明は、複数の利用者端末が通信ネットワークを介した映像データ及び音声データの送受により会議通話を行う会議通話システム、及びその会議通話システムに用いられるバックエンドシステムに関する。

１．はじめに
情報通信技術の進歩と計算機システムの性能向上により、インターネット上で映像と音声を用いて遠隔地間とリアルタイムに双方向通信を行うことは日常的に可能となった。近年では、スマートフォンやタブレットでも利用できるビデオチャットシステムや、汎用PCを用いたWeb会議システムが普及の一途をたどっている。インフォーマルかつ簡単なコミュニケーション手段としては、スマートフォンやタブレットを利用したビデオチャットが適しており、日常業務において電子的なデータを共有しつつ遠隔地と協調作業するのであれば、汎用PCを用いたWeb会議システムを利用できる。一方、専用端末を用いたビデオ会議システムはHD（High Definition）品質の高解像度な映像を扱えるようになり、企業における複数拠点をつないだ定例会議等の用途で利用されている。また、遠隔地にいる相手と対面しているような臨場感を生み出すテレプレゼンスシステムといった高機能なビデオ会議システムも実現されている。様々な用途に応じて、我々は映像と音声を用いた通信システムを選択して利用できるようになった。

一方、例えば年に数回場所を変えて不定期に行われる各種の催し事（シンポジウム／ワークショップ／セミナ等）を、複数の地点間をつないで実施する場合には、通信システムの構築および利用する機能の構成と拡張性に関して検討すべき課題がある。ここで、複数の遠隔地間で行われる映像と音声を用いた双方向通信のことを会議通話とよび、会議通話を行う各種の催し事を通信イベントとよぶことにする。最初に、通信イベントを支援する観点から、会議通話システムへの要件をまとめる。

まず、通信イベントを実施するためには、会議通話用の機材を一時的に揃えたり、専用回線や商用回線を組み合わせた通信イベント用のネットワーク環境を一時的に準備したりする必要がある。しかし、例えばビデオ会議システムの専用端末を普段利用していても、利用上または物理的な制約により、設置場所から移動できなかったり、通信イベント会場となる複数の地点全てでは揃えられなかったりすることがある。また、インターネット上でWeb会議システムを普段利用していても、インターネットとは物理的または論理的に分離されたネットワークを通信イベントで利用する場合には、Web会議システムを利用できないことがある。実際、日常的に利用している会議通話システムを通信イベント用途には適用できない状況がある。

また、通信イベント用のネットワーク環境における可用帯域幅が地点毎に異なることを想定して、利用する機能を構成する必要がある。近年の映像符号化技術の進歩によりHD品質の映像と音声も、利用する符号化方式の種類と設定次第では１本につき数Mbpsで転送可能となったが、要求される品質に応じて必要帯域幅は数Mbps〜数十Mbpsの範囲となる。高品質な映像と音声を用いて地点毎に複数本の映像と音声を送受信する場合、各地点で帯域幅を十分に確保できるとは限らない。従って、多くの可用帯域幅を確保できる会場へ各地点からの映像と音声を集め、ミキシングした映像と音声を各地点へ中継する会議通話の形態が適している。その中継機能とミキシング機能をネットワーク環境に応じて適応的に構成できる仕組みが必要とされる。

さらに、同時進行で行われる複数会議通話への対応や、地点毎のミキシング機能への対応が必要となる。例えば、複数のセッションを同時進行で行う各種のシンポジウムや、複数のプログラムを同時進行させるワークショップやセミナの実施を支援するためには、複数の会議通話を同時に実施できる仕組みが必要である。また、各地点において表示される映像の配置位置や再生される音声のボリュームを地点毎に調整するためには、地点毎に独立したミキシング機能が必要となる。これらの機能は、通信イベントの主旨や通信イベント用のネットワーク環境に応じて拡張的に利用できる仕組みが有効と考えられる。

以上をふまえ、通信イベントを支援する会議通話システムへの要件を次のとおりまとめる。
要件１：制約のある通信イベント用のネットワーク上で会議通話システムを一時的に構築できること。
要件２：ネットワーク環境に応じて映像と音声の中継機能とミキシング機能を適応的に構成できること。
要件３：同時に実施可能な会議通話数を増やせる機能と、地点毎のミキシング機能を、必要に応じて拡張的に利用できること。

通信イベントの支援を目的とし、これらの要件を満たす会議通話システムを、普段利用している機材を用いて準備するのは容易ではない。そこでここでは、通信イベントの主旨に応じて様々な構成を可能とする分散型の会議通話システムを、汎用PC上で実現する。以前よりデジタルビデオの伝送や、HD品質の映像伝送が汎用PC上で実現されているが、端末の性能向上により、携帯可能な小型の端末でもHD品質の映像と音声をリアルタイムに圧縮して送信したり、受信して再生表示したりすることが可能となった。しかし、高解像度な映像のミキシング処理に加えて圧縮処理には多くの計算機資源が必要となるので、通信イベントを支援するうえでは、一時的に構築可能で台数効果のあるバックエンドシステムが有効であると考える。

以下、２章では既存システムと関連研究について述べ、提案システムを位置づける。３章では提案する会議通話用バックエンドシステムを複数の端末を用いて構成する際の機能分散と、機能分散を考慮したプロトコルについて述べる。続く４章では、会議通話において映像と音声を複数地点間で双方向通信するためのモデルを示す。５章ではプロトタイプシステムの実装について述べ、６章でその有用性を評価し、７章で全体をまとめる。

特開２００７−７２７３９号公報

Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.: RTP: A Transport Protocol for Real-Time Applications, RFC3550 (2003). Ooi, W.T. and Renesse, V.R.: Distributing Media Transformation Over Multiple Media Gateways, Proc. 9th ACM International Multimedia Conference (2001) 橋本浩二, 柴田義孝: 利用者環境を考慮した相互通信のためのミドルウェア, 情報処理学会論文誌, Vol.46, No.2, pp.403-417 (2005) Patrick G. Bridges, Matti Hiltunen and Richard D. Schlichting: Cholla: A Framework for Composing and Coordinating Adaptations in Networked Systems, IEEE Transaction on Computers, Vol.58, No.11, pp.1456-1469 (2009) Hiroshi Nishida and Thinh Nguyen: Optimal Client-Server Assignment for Internet Distributed Systems, IEEE Transactions on Parallel and Distributed Systems, Vol.24, No.3, pp.565-575 (2013) Junwei Cao, Kai Hwang, Keqin Li, Albert Y. Zomaya: Optimal Multiserver Configuration for Profit Maximization in Cloud Computing, IEEE Transactions on Parallel and Distributed Systems, Vol.24, No.6, pp.1087-1096 (2013) Vivek Nallur, Rami Bahsoon: A Decentralized Self-Adaptation Mechanism for Service-Based Applications in the Cloud, IEEE Transactions on Software Engineering, Vol.39, No.5, pp.591-612 (2013) Fang Zhiyuan, Li Wei, Feng Zhang, Zhou Fang, Donghang Huang, Xin Dai: A Cloud-Based Pan-Terminal Video Conferencing System, Proc. IEEE 10th International Conference on e-Business Engineering, pp.445-449 (2013) Yuan Feng, Baochun Li, Bo Li: Airlift: Video conferencing as a cloud service using inter-datacenter networks, Proc. IEEE 20th International Conference on Network Protocols, pp.1-11 (2012) Hongen Feng, Wenjun Wu: Framework and user migration strategy of cloud-based video conference multigateway system, Proc. 19th International Conference on High Performance Computing, pp.1-8 (2012) Han Zhao, Daniel Smilkov, Paolo Dettori, Julio Nogima, Frank A. Schaffa, Peter Westerink, C hai Wah: A Feasibility Study of Collaborative Stream Routing in Peer-to-Peer Multiparty Video Conferencing, Proc. IEEE International Symposium on Multimedia, pp.233-240 (2011) Zhi Wang, Jizhong Zhao, Wei Xi, Zhiping Jiang: A Scalable P2P Video Conferencing System Based on VCStream Model, Proc. IEEE/ACIS 11th International Conference on Computer and Information Science, pp.77-82 (2012) Hui Guo, Kwok-Tung Lo, Yi Qian, Jiang Li: Peer-to-Peer Live Video Distribution under Heterogeneous Bandwidth Constraints, IEEE Transactions on Parallel and Distributed Systems, Vol.20, No.2, pp.233-245 (2009) Koji Hashimoto and Yoshitaka Shibata: MidField: An Adaptive Middleware System for Multipoint Digital Video Communication, Digital Video, Floriano De Rango (Ed.), ISBN: 978-953-7619-70-1, InTech, DOI: 10.5772/8032 (2010).Available from:http://www.intechopen.com/books/digital-video/midfield-an-adaptive-middleware-system-for-multipoint-digital-video-communication (accessed 2015-01-21). MSDN Library: DirectShow, available from < https://msdn.microsoft.com/en-us/library/windows/desktop/dd375454(v=vs.85).aspx > (accessed 2015-01-21) 玉木秀和, 東野豪, 小林稔, 井原雅行: 音声遅延が遠隔会議中の発話衝突と精神的ストレスに与える影響, 電子情報通信学会論文誌D, Vol.J96-D, No.1, pp.35-45 (2013) OpenLDAP Foundation: OpenLDAP, Main Page, available from <http://www.openldap.org> (accessed 2015-01-21) RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING: RECOMMENDATION ITU-R BT.1359-1 (1998) JGN-X: JGN-Xウェブサイト, 入手先 <http://www.jgn.nict.go.jp> (参照 2015-01-21). SINET4: 学術情報ネットワーク（SINET4、サイネット・フォー）, 入手先 <http://www.sinet.ad.jp> (参照 2015-01-21). Polycom: Video Conferencing, Voice Conferencing, Telepresence, 入手先 <http://www.polycom.com> (参照 2015-01-21) Business Communications Solutions from Avaya - Avaya USA, 入手先 <http://www.avaya.com> (参照 2015-01-21) 会議ソリューション - Cisco Systems, 入手先 <http://www.cisco.com/web/JP/product/hs/webex/index.html> (参照 2015-01-21) ビデオ会議システム | 法人のお客様 | ソニー, 入手先 <http://www.sony.jp/pcs> (参照 2015-01-21)

２．既存システム・関連研究と提案システム
上記の要件を満たすシステムの実現に向けて、まず、既存システムと関連研究の現状をまとめ、次に、提案システムの機能の概要を述べる。

2.1 既存システムと関連研究における課題
先に述べた要件を満たすためには、ビデオ会議システムのサーバ型MCU（多地点接続装置: Multipoint Control Unit）における、複数の会議通話を同時に実施する機能および地点毎のミキシング機能を、選択的に構成できる仕組みが必要である。MCUにはビデオ会議システムの端末内蔵型MCUとサーバ型MCUがあり、内蔵型MCUを用いるとHD品質の映像による4地点〜10地点間の通信が可能である。しかし内蔵型MCUには、地点毎のミキシング機能は搭載されておらず、複数の会議通話を同時に実施することはできない。地点毎のミキシング機能を使ったり複数の会議通話を同時に実施したりするためには、サーバ型の高機能なMCUが別途必要となる。しかし、通信イベント実施にあたり、一時的に集めやすい機材によるシステム構築を考慮した場合、サーバ型MCUの利用は前提にできない。ソフトウェアによるMCUを搭載した汎用PCで動作するシステムも存在するが、専用装置として提供されているサーバ型MCU同様、バックエンドで常時サーバとして稼動させることを想定しており、一時的な通信イベントにおける利用を前提としたものではない。

一方、中継機能とミキシング機能を一時的なバックエンドシステムで構成するにあたり、参考となる関連研究やサービスの事例がある。映像や音声データの転送プロトコルであるRTP（非特許文献１参照）には、トランスレータとミキサの機能が定義されている。トランスレータはRTPストリームにおけるフォーマット変換等をともなう中継システムであり、ミキサは複数の送信元からのRTPストリームを１つに合成して出力する中継システムである。これらの機能は、本提案システムの中継機能およびミキシング機能と同様の機能であるが、その分散構成方法はRTPでは定義されていない。トランスレータやミキサの構成に関する過去の研究としては、メディアストリームに対し、トランスレータやミキサの処理をアプリケーションレベルで行うメディアゲートウェイシステム（非特許文献２参照）や、複数のマルチキャストセッションを統合した双方向の通信セッションを実現する方法（非特許文献３参照）が提案されている。しかしこれらは会議通話における複数の構成を考慮した分散構成方法を述べたものではなく、上述した要件を満たしていない。また、映像の圧縮／展開を考慮した機能適合に関する研究（非特許文献４参照）や、インターネットにおける分散システムの最適なサーバ割当てに関する研究（非特許文献５参照）、クラウドにおける複数サーバの構成（非特許文献６参照）や非集中型の適合方法に関する研究（非特許文献７参照）等、バックエンドシステムの機能の分散構成に関して参考となる研究が報告されている。さらに、クラウドを想定した会議通話システムも研究開発されており（非特許文献８、９、１０参照）、クラウドサービスとしての事例もある。しかしながら、通信イベント用のネットワーク環境における会議通話を前提とし、中継機能とミキシング機能の拡張を必要に応じて可能とするバックエンドシステムの分散構成方法は確立されていない。

さらに、中継機能とミキシング機能をバックエンドで分散するためには、適切なストリームパスを複数の端末で動的に構成する機能が必要となる。これまでに、ビデオ会議におけるストリームのルーティングに関する研究（非特許文献１１参照）や、P2Pのビデオ会議に有効なストリームのモデルの提案（非特許文献１２参照）があり、帯域幅の制約があるヘテロジニアスな環境におけるライブビデオ配信の研究（非特許文献１３参照）も行われている。これらの研究におけるストリームのモデルは汎用のモデルとしては有用なものだが、会議通話の主な構成をバックエンドで容易に実現するための分散型ストリームモデルの提案はなされておらず検討の余地がある。

また、特許文献１に記載される多地点会議システムが知られている。この多地点会議システムは、複数のクライアント端末とMCU（Multipoint Control Unit）を含む多地点会議装置（サーバ）とがインターネット等のＩＰ網に接続された構成となっている。そして、この多地点会議装置での制御のもと、会議に参加するクライアント端末の台数が所定数以下である場合には、多地点会議装置のMCUを使うことなく、それら複数のクライアント端末相互間での映像データ及び音声データの送受信による会議通信が行われる一方、会議に参加するクライアント端末の台数が所定数を越える場合には、多地点会議装置のMCUによって各クライアント端末からの音声データや映像データが合成、編集され、それら合成、編集された音声データ及び映像データが各クライアント端末に配信されることにより会議通信が行われる。

このような多地点会議システムによれば、多地点会議装置が、会議に参加する複数のクライアント端末の台数が所定数以下の場合、会議に参加する複数のクライアント端末相互間の会議通信を制御し、それらの台数が所定数を越える場合には、音声データおよび映像データを会議に参加するクライアント端末に配信する会議通信を制御するので、会議に参加するクライアント端末の台数の応じた会議通信を選択し、クライアント端末およびデータ量を管理して最適な会議通信を実現することができ、利便性の高いシステムを構築することができる。しかしながら、このような多地点会議システムでは、多地点会議装置（MCU）が集中的に複数のクライアント端末にて行われる会議通信を制御することになるので、多地点会議装置（MCU）の規模が大きくなり、通信イベント実施にあたり、一時的にシステム構築するということが難しい。また、各クライアント端末に固有の情報（映像及びまたは音声）を提供することが考慮されておらず、多様な会議通信を行うことができない。

本発明は、このような事情に鑑みてなされたもので、通信イベント実施にあたり、一時的にシステム構築することができ、また、多様な会議通信（会議通話）を可能にする会議通話システム及びそれに用いられるバックエンドシステムを提供するものである。

本発明に係る会議通話システムは、それぞれ利用者が操作する複数の利用者端末と、該複数の利用者端末が通信ネットワークを介して接続されるバックエンドシステムとを有し、該バックエンドシステムの制御のもと、前記複数の利用者端末が映像データ及び音声データの前記通信ネットワークを介した送受により会議通話を行う会議通話システムであって、前記バックエンドシステムは、複数の中継部と、映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して前記複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する制御部とを有する構成となる。

このような構成では、各利用者端末からの映像データまたは音声データは、通信ネットワークを介してバックエンドシステムに供給される。バックエンドシステムでは、複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかが対応づけられ、前記複数の利用者端末からの映像データまたは音声データが複数の中継部を介して前記複数のミキシング部に提供される。そして、前記バックエンドシステムの各ミキシング部にて生成される映像または音声のミキシングデータが一または複数の中継部を介して対応する利用者端末に向けて配信される。これにより、各利用者端末には、対応するミキシング部にて生成される固有の映像または音声のミキシングデータを提供することができる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記複数の中継部及び複数のミキシング部を含むサーバ装置を有する構成とすることができる。

このような構成によれば、１つのサーバ装置内に複数の中継部及び複数のミキシング部が配置されるので、比較的少ない台数の利用者端末による会議通話に適したシステムを構成することができる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記複数の中継部を含むサーバ装置と、前記複数のミキシング部を含む端末装置とを有する構成とすることができる。

このような構成によれば、映像データまたは音声データの中継処理と、映像データまたは音声データの合成処理（ミキシング処理）とをサーバ装置と端末装置とに分散させることができるので、サーバ装置及び端末装置の規模を小さくすることができ、その結果、通信イベント実施にあたり、一時的にシステム構築することが容易になる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記複数の中継部を含むサーバ装置と、前記複数のミキシング部が分散配置される複数の端末装置を有する構成となる。

このような構成により、映像データまたは音声データの合成処理（ミキシング処理）を更に、複数の端末装置に分散させることができるので、各端末装置の規模を更に小さくすることができので、通信イベント実施にあたり、一時的にシステム構築することが更に容易になる。

本発明に係る会議通話システムにおいて、前記複数の端末装置のそれぞれは、前記複数のミキシング部のいずれか１つを含む構成とすることができる。

このような構成により、複数の利用者端末装置それぞれに対する映像または音声のミキシングデータが１台の端末装置に含まれるミキシング部にて生成される。

本発明に係る会議通話システムは、それぞれ利用者が操作する複数の利用者端末と、該複数の利用者端末が通信ネットワークを介して接続されるバックエンドシステムとを有し、該バックエンドシステムの制御のもと、前記複数の利用者端末が映像データ及び音声データの前記通信ネットワークを介した送受により会議通話を行う会議通話システムであって、前記バックエンドシステムは、複数の中継部と、映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する第１制御部と、前記複数の利用者端末それぞれからの映像データまたは音声データを一または複数の中継部を介して前記複数のミキシング部において共用ミキシング部として決められたものに提供し、該共用ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して前記複数の利用者端末のそれぞれに向けて配信するよう制御する第２制御部とを有する構成となる。

このような構成により、各利用者端末からの映像データまたは音声データは、通信ネットワークを介してバックエンドシステムに供給される。バックエンドシステムでは、第１制御部の制御により、複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかが対応づけられ、前記複数の利用者端末からの映像データまたは音声データが複数の中継部を介して前記複数のミキシング部に提供される。そして、前記バックエンドシステムの各ミキシング部にて生成される映像または音声のミキシングデータが一または複数の中継部を介して対応する利用者端末に向けて配信される。また、バックエンドシステムでは、第２制御部の制御により、複数の利用者端末それぞれからの映像データまたは音声データが、一または複数の中継部を介して共用ミキシング部に提供される。そして、共用ミキシング部にて生成される映像または音声のミキシングデータが一または複数の中継部を介して複数の利用者端末のそれぞれに向けて配信される。

このような構成では、例えば、バックエンドシステムの第１制御部の制御のもと、複数の利用者端末からの音声データに基づいた音声のミキシングデータを各利用者端末に向けて配信させるとともに、第２制御部の制御のもと、複数の利用者からの映像データに基づいた映像のミキシングデータを各利用者端末に向けて配信させることができる。その結果、複数の利用者端末にて、共通のミキシング映像と固有のミキシング音声を提供することができる。このように、各利用者端末に対して、固有の映像及び固有の音声のいずれか一方のミキシングデータ（第１制御の制御に基づく）を供給するとともに、共通の映像及び共通の音声のいずれか他方のミキシングデータ（第２制御部の制御に基づく）を供給することができる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記複数の中継部及び複数のミキシング部を含むサーバ装置を有する構成とすることができる。

このような構成により、１つのサーバ装置内に複数の中継部及び複数のミキシング部が配置されるので、比較的少ない台数の利用者端末による会議通話に適したシステムを構成することができる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記第１制御部の制御に係る複数の中継部及び複数のミキシング部を含む第１サーバ装置と、前記第２制御部の制御に係る複数の中継部及び共用ミキシング部を含む第２サーバ装置とを有する構成とすることができる。

このような構成により、第１制御部の制御に係る複数の中継部及び複数のミキシングと、第２制御部の制御に係る複数の中継部及び共有ミキシング部とを、第１サーバ装置と第２サーバ装置とに分散させることができるので、第１サーバ装置及び第２サーバ装置の規模を小さくすることができ、その結果、通信イベント実施にあたり、一時的にシステム構築することが容易になる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記第１制御部の制御に係る複数の中継部を含む第１サーバ装置と、前記第１制御部の制御に係る複数のミキシング部を含む第１端末装置と、前記第２制御部の制御に係る複数の中継部を含む第２サーバ装置と、前記第２制御部の制御に係る前記共用ミキシング部を含む第２端末装置とを有する構成とすることができる。

このような構成により、第１制御部の制御に係る中継処理とミキシング処理（複数のミキシング部による）とを更に第１サーバ装置と第１端末装置とに分散させることができるとともに、第２制御部の制御に係る中継処理とミキシング処理（共用ミキシング部による）とを更に第２サーバ装置と第２端末装置に分散させることができるので、通信イベント実施にあたり、一時的にシステム構築することが更に容易になる。

本発明に係る会議通話システムにおいて、前記バックエンドシステムは、前記第１制御部の制御に係る複数の制御部を含む第１サーバ装置と、前記第１制御部の制御に係る複数のミキシング部が分散配置される複数の第１端末装置と、前記第２制御部の制御に係る複数の中継部を含む第２サーバ装置と、前記第２制御部の制御に係る前記共用ミキシング部を含む第２端末装置とを有する構成とすることができる。

このような構成により、更に、第１制御部の制御に係るミキシング処理を複数の第１端末装置に分散させることができるので、通信イベント実施にあたり、一時的にシステム構築することが更に容易になる。

本発明に係る会議通話システムにおいて、前記複数の第１端末装置のそれぞれは、前記複数のミキシング部のいずれか１つを含む構成とすることができる。

このような構成により、複数の利用者端末装置それぞれに対する映像または音声のミキシングデータが１台の第１端末装置に含まれるミキシング部にて生成される。

本発明に係るバックエンドシステムは、映像データ及び音声データの通信ネットワークを介した送受により会議通話を行う複数の利用者端末と前記ネットワークを介して接続され、前記会議通話を制御するバックエンドシステムであって、複数の中継部と、映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して前記複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する制御部とを有する構成となる。

また、本発明に係るバックエンドシステムは、映像データ及び音声データの通信ネットワークを介した送受により会議通話を行う複数の利用者端末と前記ネットワークを介して接続され、前記会議通話を制御するバックエンドシステムであって、複数の中継部と、映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に配信するよう制御する第１制御部と、前記複数の利用者端末それぞれからの映像データまたは音声データを一または複数の中継部を介して前記複数のミキシング部において共用ミキシング部として決められたものに提供し、該共用ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して前記複数の利用者端末のそれぞれに向けて配信するよう制御する第２制御部とを有する構成となる。

本発明に係る会議通話システム及びバックエンドシステムによれば、各利用者端末に向けて配信されるミキシングデータを複数のミキシング部にて分散して生成することができるので、通信イベント実施にあたり、一時的に構築し易いシステムになり得る。また、各利用者端末には、対応するミキシング部にて生成される固有の映像または音声のミキシングデータを提供することができるので、多様な会議通信（会議通話）が可能となる。

本発明の実施の形態に係る会議通話システムの構成例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるバックエンドシステムの第１の構成例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるバックエンドシステムの第２の構成例を示す図である。 本発明の実施の形態に係る会議通話システムおけるバックエンドシステムの第３の構成例を示す図である。 会議オーナ（利用者端末）の状態遷移を表す状態マシン図である。 会議メンバ（利用者端末）の状態遷移を表す状態マシン図である。 本発明の実施の形態に係る会議通話システムにおける会議通話開始時のメッセージの流れを示すメッセージフロー図である。 本発明の実施の形態に係る会議通話システムにおける会議通話参加時のメッセージの流れを示すメッセージフロー図である。 本発明の実施の形態に係る会議数話システムにおけるストリームノードの接続モデルの第１の例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるストリームノードの接続モデルの第２の例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるストリームノードの接続モデルの第３の例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるストリームノードの接続モデルの第４の例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるストリームノードの接続モデルの第５の例を示す図である。 本発明の実施の形態に係る会議通話システムにおけるストリームノードの接続モデルの第６の例を示す図である。 プロトタイプシステム（汎用ＰＣ）におけるソフトウエア構成の一例を示すブロック図である。 プロトタイプシステムにおける中継及びミキサストリームノードを示す図である。 第１の評価実験環境を示すブロック図である。 第２の評価実験環境を示すブロック図である。 ４台の会議サーバそれぞれのCPU利用率の結果例を示すグラフ図である。 会議サーバにおける入力スループットの結果例を示すグラフ図である。 会議サーバにおける出力スループットの結果例を示すグラフ図である。 会議サーバのCPU利用効率の結果例を示すグラフ図である。 会議サーバの入出力スループットの結果例を示すグラフ図である。 ８台の共用端末それぞれのCPU利用率の結果例を示すグラフ図である。 エンド間遅延の結果例を示すグラフ図である。 会議サーバの入出力スループットの結果例を示すグラフ図である。 ２台の共用端末それぞれのCPU利用率の結果例を示すグラフ図である。 エンド間遅延の結果例を示すグラフ図である。 会議通信システムの第１の運用例を示す図である。 会議通信システムの第２の運用例を示す図である。

以下、本発明の実施の形態について図面を用いて説明する。

2.2 提案システムの概要
既存システムと関連研究を踏まえ、提案システム（本発明の実施の形態に係る会議会話システム）の概要を述べる。まず、要件１に対しては、一時的に準備し易い汎用PCを用いて、会議通話システムを容易に構築できるシステムの実現を目指す。要件２に対しては、通信イベント用ネットワーク環境でバックエンドシステムを一時的に構築し、中継機能とミキシング機能を構成できる仕組みを実現する。要件３については、バックエンドシステムにおける端末の数を必要に応じて増やすことで、同時に実施可能な会議通話数を増やしたり地点毎のミキシング機能を利用したりできる仕組みを実現する。

システム実現にあたり、会議通話の主な構成と構成毎に必要となるストリームパスはパターン化することができる。そのパターンに従ったストリームパスを選択的に構成できれば、中継機能とミキシング機能を複数の端末上で分散する際の複雑さが軽減され、結果として実装の容易さと運用のし易さに繋がる。そこでここでは会議通話に必要となるストリームパスをパターンに分けてモデル化する。そのパターンを用いて、映像に関しては、各地点共通の画面イメージを生成する共用ミキサと、各地点別々の画面イメージを生成する専用ミキサを選択的に利用できる仕組みを実現する。音声に関しては、会議通話の各地点における音声出力をそれぞれ調整できるよう、音声の専用ミキサを地点毎に利用できる仕組みを実現する。また、異なるストリームパスのパターンを組み合わせることにより、ネットワークの末端で利用可能な帯域幅や要求されるミキサの用途に応じて、１つの会議通話の中でも、地点毎に適切な品質の映像と音声や、共用ミキサまたは専用ミキサの機能を提供することが可能となる。

以上、提案システムの概要を述べた。通信イベントの支援を目的とし、一時的に容易に構築可能であり、バックエンドで機能分散できる会議通話システムを実現する。最小構成１台から、必要に応じて台数効果のあるバックエンドシステムを実現することが目標となる。

汎用PCを用いるので、利用する端末の性能と入出力装置によって処理可能な映像と音声の品質は変わるが、普及しているHD品質の映像を処理可能なプロトタイプシステムを実装する。近年では備え付けのプロジェクタやディスプレイも高解像度な表示装置が増え、映像入力装置としてのビデオカメラもHD品質が主流となっている。そこで、入出力装置の規格として比較的揃えやすいHD-720（720p）相当の映像を基準とし、プロトタイプシステムを構築する。

ここでは、プロトタイプシステムで使用した端末における台数効果を確認するため、複数の端末でバックエンドシステムを構成する環境を用意し実験を行った。既存の主なHD対応型ビデオ会議専用端末を用いる場合と同程度の地点間における会議通話を、汎用PCを用いたバックエンドシステムでも実現できることを実験結果から示す。さらに、高機能なサーバ型MCUを必要とする地点毎のミキシング処理を、複数台の汎用PCで分散処理することにより実現できることも実験結果から示す。

３．会議通話用バックエンドシステムの構成
中継機能とミキシング機能を複数台の汎用PCによりバックエンドで分散構成するためには、会議通話を実施する利用者の端末における状態に合わせて機能分散を行うためのプロトコルが必要となる。ここでは、まず会議通話用バックエンドシステム１００の構成を示し、会議通話を実施する利用者端末内の状態遷移について述べる。そして、会議の開催および会議への参加の際に必要となる手順を示す。

提案システムを構成する端末の概要を図１に示す。会議通話のフロントエンドとなる利用者端末１０(U: User Terminal)は、会議サーバ１１０（C: Conference Server）を利用して利用者へ会議通話の機能を提供する。会議サーバ１１０は１台でも会議通話の機能を利用者端末へ提供できるが、複数の会議通話を同時に行う際必要に応じてその会議通話数を増やせるよう、複数の会議サーバ１１０を配置することができる。複数の会議サーバ１１０を配置する場合、各利用者端末１０は、どの会議サーバ１１０を利用するかポータル会議サーバ１２０（P: Portal Conference Server）へ問い合わせ、ポータル会議サーバ１２０は適切な会議サーバ１１０を利用者端末１０へ割り当てる。また、会議情報データベース１３０（DB: Database of Conference Information）には、会議通話を実施する際に参照すべき会議室情報や利用者のアカウント情報が格納されており、ポータル会議サーバ１２０または会議サーバ１１０がその情報を参照する。さらに、複数の会議サーバ１１０から共通の計算機資源として利用でき、会議通話で要求されるミキシング機能をバックエンドシステム１００内で分散構成するための共用端末１４０（S: Shared Terminal）を、必要に応じて配置することにより、会議サーバ１１０はミキシング機能を分散させることができる。一方、会議情報データベース１３０を会議サーバ１１０に内包することで、１台の会議サーバ１１０による通信イベントの支援が可能となることも考慮する。

3.1 想定する中継機能とミキシング機能の構成
提案システムにおいて想定している中継機能とミキシング機能の構成を図２に示す。会議サーバ１１０はこれら３つの構成を組み合わせて会議通話を実施する。ここで、中継ストリームノード（rly: Relay Stream Node）は、映像・音声ストリームの中継処理をするプログラムであり、複数のストリームを中継する際は複数の中継ストリームノードが利用される。また、ミキサストリームノード（mix: Mixer Stream Node）は、映像または音声ストリームのミキシング処理（合成処理）をするプログラムであり、必要に応じて複数のミキサストリームノードが利用される。

構成１（cfg-1: Configure 1）は、中継機能のみの構成である。利用者端末１０が映像または音声を送信すると、他の利用者端末１０へ会議サーバ１１０が中継する。構成２（cfg-2: Configure 2）は、中継とミキシング（合成）機能の両方を利用する構成である。利用者端末１０が映像または音声を送信すると、中継ストリームノード経由でミキサストリームノードの入力となり、ミキシング処理が行われる。ミキシング結果は１つであり、そのコピーが複数の利用者端末１０へ送信される。構成２におけるミキサを共用ミキサと呼ぶ。共用ミキサの操作は各利用者端末１０から排他的に行うことが可能である。一方、構成３（cfg-3: Configure 3）では、構成２と同様に中継とミキシング機能の両方を利用するが、共用ミキサを利用するのではなく利用者端末１０毎のミキサを利用している。利用者端末１０毎のミキサを専用ミキサと呼ぶ。専用ミキサの操作は利用者端末１０毎に行うことが可能であり、利用者端末１０毎に異なる映像または音声のミキシング結果を受信して再生表示することが可能となる。

会議サーバ１１０は、中継機能とミキシング機能の３つの構成に対応する。会議通話の際、映像ミキサを共用ミキサとして用いて、音声ミキサは専用ミキサを利用するというような用途に対応することも考慮し、映像については構成２、音声については構成３という複合的な構成の会議通話が可能となる。

次に示す図３は、バックエンドシステム１００として複数の会議サーバ１１０を配置した例である。１台の会議サーバ１１０でも会議通話を実施できるが、複数の会議通話を同時に実施する際に要求されるネットワーク２００の帯域幅や、ミキシング処理の負荷を考慮すると、複数の会議サーバ１１０による機能分散が必要となる。図３は、cfg-1〜cfg-3の構成による通信をそれぞれ別の会議サーバ１１０で実施している図となっているが、各会議サーバ１１０は図２同様にcfg-1〜cfg-3いずれにも対応できるものとする。また、複数の会議サーバ１１０を配置する場合は、新しく会議通話を開始する際の会議サーバ１１０を選定する機能と、実施中の会議通話に対応しているのはどの会議サーバ１１０であるかを確認する機能が必要となるので、その機能を実現するためにポータル会議サーバ１２０を配置している。

さらに図４は、共用端末１４０を配置してミキシング機能を分散させた例である。構成２（cfg-2s: Configure 2 with Shared Terminal）においては、利用者端末１０への映像または音声ストリームの中継機能と、共用ミキサによるミキシング機能を分散させることが可能となる。また、構成３（cfg-3s: Configure 3 with Shared Terminals）においては、専用ミキサによるミキシング機能を複数の共用端末１４０で分散させることが可能となる。負荷の高い映像のミキシング処理も、複数の共用端末１４０を配置することで、利用者端末１０毎の専用ミキサを使うことが可能となる。

会議通話を実施する際、バックエンド（１００）における中継機能とミキシング機能を利用するためには、利用者端末１０の状態に応じたバックエンド（１００）側での機能分散処理が必要となる。引き続き、利用者端末１０内の状態と会議通話に必要な手順について述べる。

3.2 会議オーナと会議メンバの状態
上述した中継機能とミキシング機能の３つの構成を利用した会議通話の実現にあたり、提案システムでは、会議通話を開始する利用者端末１０のプログラムを会議オーナ１０（Ｏ）と呼び、会議通話に参加する利用者端末１０のプログラムを会議メンバ１０（Ｍ）と呼ぶ。各構成に対応可能なシステムを実現するために必要となる会議オーナ１０（Ｏ）と会議メンバ１０（Ｍ）の状態を、状態マシンとして示したのが図５と図６である。

図５に示す通り、会議オーナ１０（Ｏ）はClosed状態からopen-sessionイベントにより会議通話開始処理に入る。共用ミキサを必要としない場合はRegistering状態に遷移し、利用する会議サーバ１１０に会議室情報を登録する。共用ミキサを必要とする会議通話の場合はSetting Up Shared Mixer状態の中で共用ミキサをバックエンドシステム１００内に準備した上でRegistering状態に遷移する。会議サーバ１１０への会議室情報の登録が成功するとOpened状態へ遷移する。

Opened状態では、会議メンバ１０（Ｍ）の追加／削除（add-member／remove-member）、会議メンバ１０（Ｍ）によるソースストリームノードの追加／削除イベント （add-source-node／remove-source-node）に対応する処理を実行する。会議メンバが会議通話参加の際に専用ミキサの利用を要求する場合は、Setting Up Private Mixer状態へ遷移し、専用ミキサをバックエンドシステム１００内に準備した上で再度Opened状態へ戻る。ここで、会議通話に必要となるミキサの確保と解放は会議オーナ１０（Ｏ）主導で行われる。これは会議通話に必要なバックエンドシステム１００の資源を会議通話毎に一元管理することで、バックエンドシステム１００内の資源割り当てを効率よく行うためである。

また、Opened状態で処理されるイベントは全て、会議通話に参加中の会議メンバ１０（Ｍ）へも通知される。例えば、会議メンバ１０（Ｍ）の端末で映像または音声の送信を新たに開始する際には、ソースストリームノードを追加するためのメッセージが会議メンバ１お（Ｍ）から会議オーナ１０（Ｏ）へ送信され、これがadd-source-nodeイベントとなる。会議オーナ１０（Ｏ）はイベントに対し、必要に応じてストリームノードの接続を行い、その結果は全ての会議メンバ１０（Ｍ）へ通知される。

最後に会議通話を終了する際は、close-sessionイベントが発行され、Unregistering状態へ遷移する。この状態では、利用していた会議サーバ１０（Ｍ）へ登録していた会議室情報を削除する。また、バックエンドシステム１００内で利用していた共用ミキサはここで解放される。会議メンバ１０（Ｍ）は、会議通話への参加と退出、ソースストリームノードの追加と削除が可能であり、図６はその状態マシンを示している。

図６の通り、会議メンバ１０（Ｍ）はOut of Session状態からjoin-sessionイベントにより会議参加処理状態（Joining）へ遷移する。専用ミキサを利用する場合は、会議オーナ１０（Ｏ）がそのセットアップ処理を実行する。そして、共用か専用かに関わらずミキサをバックエンド（１００）で利用する場合は、Setting Up Mixer Sink状態に遷移し、バックエンド（１００）のミキサストリームノードから利用者端末１０へのストリームノードまでの接続を行う。

会議通話に参加すると、In Session状態へ遷移する。この状態では、ソースストリームノードの追加／削除（add-source-node／remove-source-node）が可能である。また、他の利用者端末１０において追加されたソースストリームノードの情報を会議オーナから受け取った場合、これをset-up-sink-nodeイベントとして扱いSetting Up Sink Node状態へ遷移し、他の利用者端末１０で送信が始まった映像・音声を受信するためのストリームノードを生成する。ここで必要となるストリームノードは、中継機能とミキシング機能の構成によって、利用者端末１０内であるかバックエンドシステム１００の端末内であるかが決まる。その詳細は第４章で述べる。

会議通話から退出する際は、leave-sessionイベントが発行されRemoving All状態へ遷移する。ソースストリームノードは全てこの状態の中で会議通話から削除され、専用ミキサを利用していた場合もこの状態の中でバックエンドシステム１００における資源の解放処理が実行される。最後にLeaving状態では、会議オーナ１０（Ｏ）へ退出メッセージを送信してその返信を受け、会議通話からの退出が完了する。

ここまで、会議オーナ１０（Ｏ）と会議メンバ１０（Ｍ）それぞれの状態マシンについて述べた。引き続き、会議オーナ１０（Ｏ）による会議通話の開始手順、および会議オーナ１０（Ｏ）と会議メンバ１０（Ｍ）が連携動作する会議通話への参加の手順について述べる。

3.3 会議開始と参加の手順
会議通話を行うためには、バックエンドシステム１００として配置されている複数の端末とフロントエンドの利用者端末１０間におけるメッセージ交換が必要となる。本実施の形態における会議通話用のバックエンドシステム１００は、通信イベント実施の際一時的に構築されることを想定しており、構成端末の台数は可変である。しかし、会議情報データベース１３０を内包する１台の会議サーバ１１０のみでバックエンド（１００）が構成されているか、複数の端末で構成されているかに関わらず、利用者端末１０側では同じ手順で会議通話を実施できることが望ましい。既に述べた会議オーナ１０（Ｏ）と会議メンバ１０（Ｍ）の状態マシンは利用者端末１０内の状態であるが、バックエンドシステム１００では利用者端末１０内の状態とバックエンド（１００）を構成する端末数に応じて適切な会議サーバ１１０と共用端末１４０を会議通話に適用する必要がある。これらを考慮した、会議通話を開始する際のメッセージフローを図７に、会議通話へ参加する際のメッセージフローを図８に示す。

会議通話を行う際には、予め会議情報データベース１３０に格納されている会議室情報を参照する。会議室情報には、会議室名と参加可能な利用者IDが含まれている。一方、会議通話中に変化し得る情報は会議オーナ１０（Ｏ）が管理する。本提案システムではこれを会議通話情報と呼ぶ。会議通話情報には、現在会議通話へ参加している利用者および利用者の端末情報や、送受信されている映像と音声ストリームのパスなどが含まれる。

会議通話を開始する際、会議オーナ１０（Ｏ）となる利用者端末（図７におけるConference Owner）は、最初にRoom Status Requestメッセージをポータル会議サーバ１２０へ送信する（１）。ポータル会議サーバ１２０は、必要に応じて利用者認証を行った後、会議室情報を会議情報データベース１３０へ問い合わせる（Room Information Request and Response）（２）。次に複数の会議サーバ１１０へServer Status Requestメッセージを送信し、その応答を受ける（３）。この応答には会議サーバ１１０の資源利用状況としてCPU利用率と使用帯域が含まれている。ポータル会議サーバ１２０は負荷の低い会議サーバ１１０を選び、そのサーバ１１０のIPアドレスを含むRoom Status Responseメッセージを会議オーナ１０（Ｏ）の利用者端末へ送り返す（４）。ここまでは、利用者端末１０におけるClosed状態（図５）の処理となる。引き続き、会議オーナ１０（Ｏ）の利用者端末は、選択された会議サーバ１１０上で会議通話を開始するための準備を進める。開始する会議通話が共用ミキサを用いる場合は、会議サーバ１１０に対してSetup Node Requestメッセージを送信する（５）。会議サーバ１１０は利用可能な共用端末１４０の資源利用状況を問い合わせ（Resource Status Requests and Responses）（６）、負荷の低い共用端末１４０上で共用ミキサを動作させる準備を進める（７）。これは、利用者端末１０におけるSetting Up Shared Mixer状態（図５）の処理となる。その後、図５におけるRegistering状態へ遷移した利用者端末１０はRegister Conference Property Requestメッセージを会議サーバ１１０へ送信し（８）、開始する会議室情報を登録する。登録後（９）、会議オーナ１０（Ｏ）の利用者端末はOpened状態（図５）へ遷移し、会議参加要要求に対応できる状態となる。ここで、共用ミキサを用いない場合は、図７における（５）〜（７）のメッセージの送受信は行われない。

会議通話へ参加する際は、会議メンバ１０（Ｍ）となる利用者端末（図８におけるConference Member）が、最初にConference Property Requestメッセージをポータル会議サーバ１２０へ送信する（１）。会議通話開始時の流れ同様、必要に応じて利用者認証が行われ、会議室情報を会議情報データベース１３０へ問い合わせる（２）。次に複数の会議サーバ１１０へSuitable Property Requestメッセージを送信し（３）、その応答を受ける。この応答には、各会議サーバ１１０で現在実施されている会議室情報が含まれている。ポータル会議サーバ１２０は、会議メンバ１０（Ｍ）が参加できる会議通話を実施している会議サーバ１１０の会議室情報をリスト化しConference Property Responseメッセージを会議メンバ１０（Ｍ）の利用者端末へ送り返す（４）。ここまでは、利用者端末１０におけるOut of Session状態（図６）の処理となる。

引き続き、会議メンバ１０（Ｍ）の利用者端末は、参加する会議通話を実施している会議サーバ１１０を経由して会議オーナ１０（Ｏ）へJoin Conference Requestメッセージを送信する（５）。ここで利用者端末１０の状態は図６のJoining状態に遷移する。会議通話に参加する会議メンバ１０（Ｍ）が専用ミキサを利用する場合、会議オーナ１０（Ｏ）はSetting Up Private Mixer状態（図５）へ遷移し、専用ミキサを共用端末１４０上で動作させる準備を進める（図８の（６）〜（８）)。専用ミキサの準備が終了すると、会議オーナ１０（Ｏ）はOpened状態（図５）へ遷移し、会議メンバ１０（Ｍ）へJoin Conference Responseメッセージを送る（９）。その後、会議メンバ１０（Ｍ）側では、必要に応じてミキサからの出力を受けるシンクストリームノードを準備し、会議通話参加状態となる。

以上、第３章では、提案システムの構成を示し、利用者端末１０内のプログラムの状態マシン、および会議通話開始と参加に必要となるメッセージフローを示した。続く第４章では、映像と音声の双方向通信を行うためのストリームノードの接続について、構成毎に整理してモデルを示す。

４．ストリームノードの接続モデル
会議通話者が映像または音声の送信を開始したり終了したりするタイミングで、ストリームの適切な接続処理が必要となる。中継機能とミキシング機能を構成するためのストリームパスを整理すると、構成毎にパターン化することができる。提案システムでは、パターン化されたストリームパスを必要に応じて選択的に構成することで会議通話を実現する。以下、構成毎にパターン化されたストリームノードの接続モデルについて述べる。

4.1 各構成におけるストリームノードの接続
Cfg-1（図２）は中継処理のみを必要とする構成であり、図９はそのストリームノードの接続モデルを示している。図９は、会議サーバ１１０を利用して３台の利用者端末１０間で会議通話を行っている例であり、映像または音声データ送信の始点となるソースストリームノードをsrcと表し、映像または音声データを受信して表示または再生する終点となるシンクストリームノードをsnkと表している。

図９は、利用者端末１０（Ｕ1）のみが映像または音声データを１本送信している状態を示している。利用者端末１０上でソースストリームノードが追加されると、会議サーバ１１０（Ｃ）の中には中継ノードが生成され、他の利用者端末１１０（Ｕ2とＵ3）ではそれぞれシンクストリームノードが生成される。ソースストリームノードが削除される際は、そのソースストリームノードを始点とするストリームノードのパス全体が削除される。

cfg-2（図２）は、バックエンドにおいて共用ミキサを利用する構成であり、図１０Ａはそのストリームノードの接続モデルを示している。共用ミキサを利用する場合、会議通話開始時に会議オーナ１０（Ｏ）が共用ミキサを準備し、会議メンバ１０（Ｍ）は会議通話参加時に共用ミキサから利用者端末１０までのストリームノードを予め接続しておく。利用者端末１０においてソースストリームノードが追加／削除されるタイミングで、会議サーバ１１０上でも中継ストリームノードが追加／削除される。会議サーバ１１０上の中継ストリームノードは、共用ミキサの入力となる。

一方、図１０Ｂは共用端末１４０を利用する構成cfg-2s（図４）におけるストリームノードの接続モデルを示している。共用端末１４０を利用していない場合と同様、共用ミキサから利用者端末までのストリームノードは予め接続される。利用者端末１０においてソースストリームノードが追加／削除されるタイミングで、会議サーバ１１０と共用端末１４０間も中継ストリームノードによってストリームのパスが追加／削除される。

会議通話cfg-3（図２）は、バックエンド（１００）において専用ミキサを利用する構成であり、図１１Ａはそのストリームノードの接続モデルを示している。会議メンバ１０（Ｍ）は会議通話へ参加する際に会議オーナ１０（Ｏ）経由で専用ミキサを準備する。また、会議メンバ１０（Ｍ）は会議通話参加時に専用ミキサから利用者端末１０までのストリームノードを予め接続しておく。利用者端末１０毎のミキサノードへ入力を与える中継ストリームノードは、ソースストリームノードから１本のストリームを受信すると、端末内で複数のミキサノードへストリームデータを分配する。図１１Ｂは１台の共用端末１４０を利用した場合の構成cfg-3s（図４）におけるストリームノードの接続モデルである。

そして図１２は、構成cfg-3sにおいて、複数台の共用端末１４０を利用した場合のストリームノードの接続モデルを示している。この図では、利用者端末１０と同数の共用端末１４０が配置され、それぞれの共用端末１４０内で利用者端末１１０毎のミキシング処理を行っている。利用者端末１０上でソースストリームノードが追加されると、会議サーバ１１０に中継ストリームノードが生成される。１台の共用端末１４０の場合と異なり、生成された中継ストリームノードは各共用端末１４０のミキサストリームノードへストリームデータを中継する。

ここまで、各構成におけるストリームノードの接続モデルを示した。パターン化されたモデルを用いることで、中継機能とミキシング機能を複数の端末上で分散させる際の複雑さの軽減が期待できる。一方、機能を分散することにより、バックエンド（１００）を構成する端末間で送受信されるストリームの数は増える。ストリームモデルを実際の会議通話へ適用することを考慮すると、バックエンドシステム１００における台数効果にストリーム数が関係するので、次に、各構成において必要となる入出力ストリーム数を整理する。

4.2 各構成と入出力ストリーム数
表１の通り、バックエンド（１００）で必要となる入出力ストリーム数は構成毎に異なる。ここで、Ｎ台の利用者端末が１つの会議通話に参加していることを想定し、各利用者端末１０からは１つのソースストリームノードによる映像または音声ストリームが送信されているものとする。また、各構成におけるストリームノードの接続モデルに従って各端末は中継とミキシング処理を行っているものとする。

表に示す通り、cfg-1における利用者端末１０と会議サーバ１１０の入力ストリーム数は利用者端末１０の数に比例するが、会議サーバ１１０の出力ストリーム数は利用者端末１０数の二乗に比例する。cfg-2以降の利用者端末１０における入出力ストリーム数は、入力出力共に１本であるが、その分、バックエンドシステム１００側のストリーム数は増える。会議通話を構成する端末毎のストリームの本数のみを考慮すると、Ｎ台の利用者端末１０と同数の共用端末１４０をバックエンド（１００）に配置した場合cfg-3s（(M shared terminals: M=N)における会議サーバ１１０の出力ストリーム数が最も多くなる。

cfg-1において、各利用者端末１０が受信する映像・音声ストリームの数は、その利用者端末１０以外の利用者端末から送信されている映像・音声ストリームの数と同じである。映像・音声のミキシング処理をバックエンド（１００）で行わないので、ミキシング処理が必要となる構成２（cfg-2、cfg-2s）および構成３（cfg-3、cfg-3s）に比べるとバックエンド（１００）の負荷は低い。一方で、利用者端末１０では複数本の映像・音声ストリームを受信し、再生表示する必要があるので、特に高解像度の映像を用いる場合は、利用者端末１０の負荷が高くなる構成と言える。

共用ミキサを利用する構成２（cfg-2、cfg-2s）では、バックエンドシステム１００内でミキシング処理を行うため、バックエンド（１００）の負荷は構成１に比べて高くなるが、利用者端末１０の負荷は構成１に比べて低くなる。

そして、専用ミキサを利用する構成３（cfg-3、cgf-3s）では、複数のミキシング処理を必要とするのでバックエンドシステム１００内では構成２より負荷がかかるが、利用者端末１０の負荷は構成２と同様となる。

映像または音声ストリームが必要とするビットレートは、要求される映像と音声の品質や会議通話を構成する各端末の性能、そして利用するネットワーク環境に依存する。表１は入出力ストリームの数のみを示しているが、利用するストリームのビットレートが決まると、会議通話で必要となる帯域幅も求められる。しかし、必要となる帯域幅が求められたとしても、その構成での会議通話が可能であるかは、バックエンドシステム１００を構成する端末の性能に依存する。提案システムは、バックエンドシステム１００を構成する端末の性能を限定するものではないが、提案システムを用いて各構成の会議通話が実現可能であることを示し、バックエンドシステム１００に配置する端末の数に応じて機能的な拡張が可能となることを示すために、プロトタイプシステムを用いて機能的な評価実験を行う。続く第５章ではそのプロトタイプシステムの実装について述べる。

５．プロトタイプシステムの実装
中継処理とミキシング処理の分散構成における会議通話の実現に関して、実機を用いた機能的な検証を行うため、Windows（登録商標）７を搭載した汎用PC５０上にプロトタイプシステムを実装した。図１３は利用者端末１０、会議サーバ１１０および共用端末１４０上で動作するソフトウェアの構成概要を示している。

まず、各端末で動作するソフトウェアの共通コンポーネント５１として、本システム内部で発生する各種のイベントを処理するためのSystem Event Handler５１１を、複数のスレッドプールを用いて実装した。独立した各種のイベントを複数のスレッド上で処理させる一方、時間的に直列した処理を必要とするメッセージの配送などには単一のスレッドを用いている。また、メッセージ用とストリーミング用の複数のTCPコネクションを管理し、端末間のメッセージ送受信処理を行うためのInter-System Message Handler５１２を実装した。図７と図８で示したメッセージのためのパケット送受信はここで行われる。SIP同様にテキストベースのメッセージプロトコルを実装した。

会議通話を実施するために必要となる会議オーナ１０（Ｏ）と会議メンバ１０（Ｍ）の機能は、利用者端末１０でのみ動作するConference Components５４として実装した。これらのソフトウェアコンポーネント（Conference Owner５４２およびConference Member５４３）が、図５と図６に示した状態遷移マシンを実装し、図７と図８に示した会議通話毎のメッセージの処理を行う。アプリケーション５５に対しては会議通話に関する各種の操作をまとめたConference API ５４１を提供する一方、Conference Member５４３はStream Components５３のStream API５３１を通して映像と音声の送受信を行う。また、入出力ストリームのビットレートやCPU利用率の測定、および会議通話毎のメッセージ以外のシステムメッセージを処理するためにSystem Components５２（System API５２１、System Agent５２２）を実装した。

映像と音声のストリーミング機能は、既存システム（非特許文献１４参照）のストリーミング機能を改良し、図１３におけるStream Node５３２として実装した。Stream Node５３２の内部におけるメディア処理のフレームワークとしてはDirect Show（非特許文献１５参照）を用いており、映像と音声の伝送にはRTPを基礎としたプロトコルをTCP上で用いている。ストリーム転送用のパケットヘッダには、シーケンスナンバーとペイロードタイプ、および、ビデオフレーム(またはオーディオサンプルデータ)を分割した場合のオフセット値と、分割の最後を示すマーカービットが含まれている。

一方、非特許文献１４におけるストリーミング機能には、複数の端末によるストリームの多段接続機能が実装されているので、プロトタイプシステム（５０）ではその機能を使い、パターン化されたストリームノードの接続モデル（図９〜図１２)を実現した。加えて、ストリームノード毎に識別子（UUID）を割り当て、ストリーム用のコネクション確立時にその識別子を送信元へ伝えることにより、ストリーム用のコネクションとストリームノードを管理している。これにより、ストリームノードが端末をまたがり多段結合した際に、送信元では端末内に送信ツリーを構成し、中継状況を把握できる仕組みを実装している。

また、映像および音声ミキサも非特許文献１４におけるミキサ機能を改良して実装した。非特許文献１４で実装されているミキサでは、入力を動的に追加／削除することができない。そこで本プロトタイプシステム（５０）では、図１４に示す通りミキサの入力として動的に追加／削除可能なリングバッファを中継ストリーム毎に用意し、中継ストリームノードの出力先を、そのリングバッファへ繋ぐ仕組みを新たに実装した。映像ミキサの機能としては、複数の入力映像をタイル状に並べるTiled Viewと、縦または横一列に並べるBox Viewの２つの表示を組み合わせたレイアウトを可能とし、そのレイアウトを複数用意して切り替える機能も実装した。音声ミキサの機能としては、PCMデータのミキサと音量調整機能を実装した。そして、これらの機能を遠隔から利用可能なインターフェースを用意し、Inter-System Message Handler５１２によるメッセージ通信機能を使って遠隔からのミキシング操作を実現している。

ミキサの入力となるリングバッファからは、ミキサノードが一定間隔(評価実験では、映像は1/30sec.、音声は1/25sec.でストリームデータを取得している。その際、バックエンドシステム内における処理の時間的な揺らぎを吸収するため、ミキサの入力となるリングバッファにてバッファリング（映像は2/30sec、音声は2/25sec）をしているので、その分遅延する。一方、ミキシング処理と宛先毎の送信処理を異なるスレッドに分けることにより処理の並列性を高め、中継時の遅延を抑える実装となっている。非特許文献１６では、Web会議システムにおいて発話衝突並びに精神的ストレスが生じないようにするにはエンド間の音声遅延量を200ms以下に抑えることが必要であるとしているが、プロトタイプシステム（５０）は、共用端末１４０を用いた専用ミキサを適用した場合でも、この制約内での会議通話を実現している。

一方、会議情報データベース１３０および利用者認証には、企業内ネットワーク等で利用されているLDAP（Lightweight Directory Access Protocol）サーバを適用し、プロトタイプシステム（５０）ではWindows（登録商標）用のOpen LDAP（非特許文献１７参照）を用いた。Open LDAPのプログラムは、会議サーバ１１０やポータル会議サーバ１２０の端末内で動作させることも可能であるので、最小構成として１台の会議サーバ１１０でのバックエンドシステム１００も実現することができる。評価実験においても、会議サーバ１１０またはポータル会議サーバ１２０の端末上でOpen LDAPを動作させて実験を行った。

また、プロトタイプシステム（５０）では、利用者端末１０がポータル会議サーバ１２０へメッセージ通信用のTCPコネクションを確立した直後にLDAPを用いた利用者認証を行っている。一方、利用者端末１０が会議通話を実施する際には会議サーバ１１０へもメッセージ通信用のTCPコネクションを確立するので、その際もLDAPを用いた利用者認証を行っている。利用者端末１０がバックエンドシステム１００を利用するためには、ポータル会議サーバ１２０または会議サーバ１１０への接続が必要であるので、その両方への接続時に利用者認証を行っている。

６．評価実験と運用事例
プロトタイプシステムを実装した汎用PC５０を用いて、実験用のバックエンドシステム１００を構築し、評価実験を行った。

利用者端末１０における映像と音声のキャプチャには、各利用者端末１０に搭載されているビデオカメラとマイクロフォンを用いた。キャプチャ映像には、720p（ピクセル解像度：1280×720pixel、フレームレート：30fps）およびPCM（チャンネル数：1、サンプリング周波数：44.1kHz、量子化ビット数：16bit、キャプチャ間隔：1/25sec.）のフォーマットを用いている。映像の圧縮にはWMV（Windows （登録商標）Media Video）のCBR(Constant Bit Rate) 8Mbpsの設定を利用した。音声はキャプチャしたPCMデータを圧縮せずにそのまま705.6Kbpsの音声データを利用している。

汎用PC５０を用いているので、処理可能な映像と音声の品質は利用している端末の性能に依存する。しかし、台数効果による機能の拡張が可能であることを確認するためには、プロトタイプシステム（５０）で利用している端末における処理能力の上限を把握しておく必要がある。評価実験で用いたWMVでは720pの映像を2Mbps程度まで圧縮することが可能だが、バックエンド（１００）における入出力スループットの上限も確認するために、評価実験ではCBR 8Mbpsの設定を用いた。一方、共用端末において専用ミキサの分散機能を確認する実験においては、利用するフォーマットによる台数効果の違いを確認するために360p（ピクセル解像度：640×360pixel、フレームレート：30fps）のキャプチャ映像とWMV CBR 2Mbpsの設定も併せて用いた。

図１５Ａ、図１５Ｂに評価実験環境を示す。ポータル会議サーバ１２０を利用した複数会議サーバ１１０による機能分散機能の確認と、各構成の会議通話を１台の会議サーバ１１０で実施した場合に会議通話可能な利用者端末１０数を確認するために、図１５Ａの環境を利用した。また、共用端末１４０を利用したミキサの機能分散の評価を行うためには、図１５Ｂの実験環境を利用した。また、バックエンド（１００）を構成する端末として用いた汎用PC５０のスペックとしてCPUとNICの一覧を表２に示す。会議サーバ１１０（Ｃ1〜Ｃ4）と共用端末１４０（Ｓ1〜Ｓ4）は同じ端末であるが、図１５Ａと図１５Ｂの実験環境それぞれで役割を変更して実験を行った。利用者端末１０としては、上述した映像と音声処理に対応できる性能、かつ、ビデオカメラとマイクロフォンを搭載している汎用PC５０を用いた。

以下、各評価実験とその結果について述べる。

6.1 ポータル会議サーバによる会議通話の分散
まず、ポータル会議サーバ１２０が複数台の会議サーバ１１０へミキシング処理を振り分けられることを確認する。

実験は図１５Ａの環境を用いて行い、映像ストリームにはcfg-2の共用ミキサを、音声ストリームにはcfg-3の専用ミキサを適用した。ポータル会議サーバ１２０は、図７および図８に示す通り１台とし、会議サーバ１１０は同型の端末を４台用いた。ここで、１つの会議通話につき４台の利用者端末１０が参加することを想定すると、映像にcfg-2の共用ミキサを適用した場合、次節における１台の会議サーバ１１０の性能（図１９）から１つの会議通話に対して約32%のCPU資源が必要となる。したがって、１台の会議サーバ１１０で処理可能な会議通話数はせいぜい３つなので、４台の会議サーバ１１０に対して１２台の利用者端末１０を用いた。また、図１５Ａの実験環境におけるポータル会議サーバ１２０は、会議情報データベース１３０を内包している。

図１５Ａの環境において、１２台の利用者端末１０がＵ1からＵ12の順番でそれぞれ会議通話を開始した場合の、４台の会議サーバ１１０のCPU利用率を測定した。それぞれの利用者端末１０が会議通話開始後、約３分間、１秒毎に測定したCPU利用率の平均値をグラフにしたのが図１６である。図１６の縦軸およびグラフの下表は各会議サーバ１１０のCPU利用率を示しており、横軸は会議通話数を示している。ポータル会議サーバ１２０が機能分散を行う際に利用するCPU利用率の値としては、各会議サーバ１１０における過去30サンプル（30秒間）のCPU利用率の移動平均値を用いた。

図１６の通り、会議サーバ１１０のCPU利用状況に応じて負荷の低い会議サーバ１１０が選択されることを確認できた。図１５Ａにおいて、会議通話の数が６から７に増えた時のみ、Ｃ2（15.4%）よりもCPU利用率が高いＣ4（15.6%）が選択されている。図１６のグラフ下部に示している値は上述した通り約3分間の平均値であり、ポータル会議サーバ１２０が各会議サーバ１１０へCPU利用率を問い合わせた際のCPU利用率は、Ｃ2が15.88%、Ｃ4は15.47%だった。つまり問い合わせた時点でCPU利用率の低かったＣ4が選択され、利用者端末１０に割り当てられたことになる。また実験を通して、映像ストリームは図１０Ａ、音声ストリームは図１１Ａの通りにストリームの接続が行われストリーミング処理が行われたことを確認した。

プロトタイプシステムで用いている会議サーバ１１０では、720pの映像ミキサを１つ動作させる毎に15〜16%のCPU資源を必要とする。当然、会議通話参加者が増える毎に、より多くのCPU資源が必要となる。CPU負荷の分散にはラウンドロビンを用いる手法や、コネクション数で端末を選択する手法などがあるが、ミキシング処理に多くのCPU資源を必要とする会議通話のバックエンドシステム１００における機能分散方法としては、CPU利用率による振り分け方法が効果的に機能するものと考えられる。

6.2 １台の会議サーバにおける各構成の会議通話
引き続き、１台の会議サーバ１１０）における性能評価実験の結果をまとめる。cfg-1、 cfg-2 および cfg-3それぞれの構成で会議通話を実施した場合に、参加する利用者端末１０の数を増加させて会議サーバ１１０の性能評価を行った。

実験では、1台の利用者端末１０で会議通話を開始し、その端末１０が会議通話へ参加する。以後、残りの利用者端末１０は順番に会議通話へ参加する。各利用者端末１０は会議通話へ参加した後、映像と音声ストリームを各１本ずつ送信する。映像データは約8Mbps、音声データは705.6Kbpsである。映像および音声データの送信の際にはそれぞれ1,200byteと1,000byteにデータを分割した後12byteのヘッダを付加したパケットを、TCPを用いて送受信している。測定した入出力スループットは、この12byteのヘッダが付加された状態のデータストリームのものであり、TCP以下の層で付加されるヘッダデータは測定値に含まれない。ここで、映像データの圧縮にはCBRを用いているが入力映像によって圧縮後のビットレートは若干変動するので、結果的に映像１本と音声１本を合わせて２本分のストリームに必要とされるビットレートは約9Mbpsである。従って、表１にまとめた各構成における入出力ストリーム数に9Mbpsを掛けた値が、スループットの計測値に対する比較の目安となる。

ここで表１より、会議通話に参加する利用者端末１０の台数（Ｎ）が１１以上で、cfg-1とcfg-3s（M shared terminals: M=N）における会議サーバ１１０のアプリケーションレベルの出力ビットレートは1Gbps以上必要となる。プロトタイプシステムの各端末のNICおよびネットワークスイッチには、普及している1000Base-Tを用いているので、会議通話に参加可能な利用者端末１０の台数の上限は明らかに１１未満である。従って、１２台の利用者端末１０で構成されている図１５Ａの環境であれば１台の会議サーバ１１０における性能の上限を充分確認できるので、この実験でも図１５Ａの環境を用いた。

会議サーバ１１０における入出力スループットとCPU利用率の測定結果を図１７〜図１９のグラフにまとめる。これらの図の横軸は会議通話に参加している利用者端末１０の数を示している。縦軸とグラフ下部の表は入出力スループット（図１７、図１８）またはCPU利用率（図１９）の測定値である。

cfg-1の構成を利用する会議通話では、表１に示す通り、会議サーバ１１０の入力スループットは利用者端末１０の数Ｎに比例し、出力スループットはＮ・（Ｎ−１）に比例する。実験では、９台の利用者端末１０までは充分な入出力スループットが得られた。利用者端末１０の１０台目以降は、図１７および図１８において点線で示した理論値に対して充分なスループットが得られていない。一方、１０台の利用者端末１０を用いた際のCPU利用率は図１９から15.8%であり、CPU資源には余裕があるが、ネットワークの入出力処理がアプリケーションレベルの上限付近に達したと考えられる。結果として、プロトタイプシステムにおけるcfg-1の会議通話に参加可能な利用者端末１０の台数の上限は９台となる。

cfg-2（音声はcfg-3）の構成を用いた会議通話における会議サーバ１１０の入出力スループットは、音声ストリームに必要となるスループットに比べて映像ストリームに必要となるスループットが明らかに多く、表１のcfg-2に示す通り、ほぼＮに比例する。実験において、入力スループットは９台の利用者端末１０まで充分に得られた。cfg-1と同様に、利用者端末１０の１０台目以降は、図１７において点線で示した理論値に対して充分なスループットが得られていない。また、図１８より、出力スループットは８台の利用者端末１０まで充分得られたが、９台目以降は点線で示した理論値に対して充分でない。結果としては、cfg-2（音声はcfg-3）の構成を利用する会議通話への参加可能な利用者端末１０の台数の上限は８台である。一方、図１９より、９台の利用者端末１０を使用する際のCPU利用率は72.4%と比較的高い値を計測しているが、まだ余裕がある。従って、ミキシング処理及びその出力を各利用者端末へ送信する処理に改良の余地があると考えられる。

cfg-3の構成を用いた会議通話は、利用者端末１０毎に専用ミキサを利用するので会議サーバ１１０の負荷も高くなる。図１９より、利用者端末１０の台数が３台になった時点でCPU利用率は99.6%であり、図１８の出力スループットも、利用者端末１０の台数が２台から３台へ増加する際、増加しない。プロトタイプシステムにおけるcfg-3への参加可能な利用者端末１０の台数の上限は、720pの映像を用いた場合は２台となる。

ここまで、実験結果をもとにプロトタイプシステムにおける１台の会議サーバ１１０で会議通話可能な利用者端末１０の台数を確認した。結果として参加可能な利用者端末１０の台数は、cfg-1では９台、cfg-2では８台、cfg-3では２台である。cfg-1とcfg-2の構成を用いる場合は、既存のHD対応型ビデオ会議専用端末を用いる場合と同程度の地点数における会議通話が、汎用PC５０を用いたバックエンドシステムでも実現できることを確認した。一方、提案システムでは、ポータル会議サーバ１２０により複数の会議サーバ１１０を用いることが可能なので、必要に応じて複数台の会議サーバ１１０を用意すれば、同時に実施可能な会議通話数を増やすことも可能となる。

6.3 複数の共用端末による専用ミキサの機能分散
引き続き、共用端末１４０を用いた専用ミキサの機能分散の実験結果をまとめる。cfg-3s（M shared terminal）の構成を利用する会議通話では、バックエンド（１００）に配置する共用端末１４０の数を増やすことによって参加可能な利用者端末１０の数を増やすことが可能となる。１台の会議サーバ１１０におけるcfg-2（音声はcfg-3）の実験結果から、720pの共用ミキサを用いた場合、会議通話に参加可能な利用者端末１０の台数は８台であることがわかっている。したがって、会議サーバ１１０と同様の性能の８台の共用端末１４０を用意することにより、cfg-3sの会議通話へ参加できる利用者端末１０の台数も８台まで増やすことができると期待できる。この台数効果を確認するため、図１５Ｂの実験環境でcfg-3s（M shared terminal）の構成を利用する会議通話を実施し、参加する利用者端末１０の台数を１〜８台へ増加させる実験を行った。図１５Ｂの実験環境は、会議情報データベースとポータル会議サーバ１２０の機能を内包する１台の会議サーバ１１０、共用端末１４０と利用者端末１０がそれぞれ８台で構成されている。

また、利用するフォーマットによる台数効果の違いを確認するために360p（ピクセル解像度：1280×720pixel、フレームレート：30fps）のキャプチャ映像とWMV CBR 2Mbpsのストリームによる実験も行った。この実験では８台の利用者端末１０に対して２台の共用端末１４０を用い、利用者端末１０毎の専用ミキサが、２台の共用端末１４０で動作することを示す。

さらに、映像と音声のエンド間遅延も測定した。映像のエンド間遅延は、利用者端末１０においてビデオカメラからキャプチャしたビデオフレームのキャプチャ時刻に対して、そのビデオフレームが共用端末１４０上でミキシング後に利用者端末１０で表示されるまでの時間を計測することで求めた。音声のエンド間遅延は、利用者端末１０のマイクロフォンのそばで1kHzの音を50ms間発生させ、共用端末１４０経由で戻ってきた同じ音が、利用者端末１０のスピーカーから発せられるまでの時間を計測した。ICレコーダを用いて２つの音を録音し、録音データから1kHz 50msの信号を抜き出し、その発音開始時刻の差を求めた。利用者端末１０の台数を増加させるたびに、映像および音声とも計測を１０回行った。

会議サーバ１１０における入出力スループットと共用端末１４０のCPU利用率の累計、および利用者端末１０におけるエンド間遅延の測定結果を720pと360pで分けてそれぞれ図２０〜図２２と図２３〜図２５に示す。各図の横軸は会議通話に参加した利用者端末１０の台数である。図２２と図２５に示すエンド間遅は、計測値の平均を棒グラフで示し、その最大値と最小値もグラフに記載した。

この構成では、表１に示す通り、会議サーバの入力スループットは２Ｎに比例し、出力スループットはＮ・（Ｍ+１）に比例する。実験から、720pと360pのそれぞれにおいて充分な入出力スループットが得られていたことを確認し、利用者端末１０が会議通話へ参加する時点でCPU利用率の低い共用端末１４０が利用者端末１０へ割り当てられたことも確認できた。

映像ミキサでは、デコードされた映像フレーム（RGBデータ）の矩形サイズ変換処理とアルファブレンド処理を行い、映像ミキサの出力用のメモリ領域へ処理されたRGBデータをコピーし、その後WMVによる圧縮処理をしている。今回の実験では、それぞれの専用ミキサにおいて、１つの入力映像を全体に表示させ、その他の映像はPicture-in-Pictureとして画面下部へ横に並べた。図２１と図２４は、共用端末１４０のCPU利用率の累計を示すと共に、会議通話に参加する利用者端末１０が増えた場合にそれぞれどの共用端末１４０が割り当てられたかも示している。ここで、CPU資源の多くは圧縮処理に依存しているので、ミキシング結果の映像がフレーム内またはフレーム間の変化が少ない映像である場合、CPU資源の消費は少なくなる。従って、ミキサの処理内容によってはミキサ処理が割り当てられる共用端末１４０も変わる可能性はある。現在のプロトタイプシステムでは、単純にCPU利用率の低い共用端末１４０に対してミキサ処理を割り当てており、ミキシング処理後の映像内容を考慮した共用端末１４０の割り当てに関しては、今後アルゴリズム検討の余地があると考えている。

また、エンド間遅延の測定結果より、映像と音声ともに200ms以下の遅延（非特許文献１６参照）で動作したしたことも確認した。図２２および図２５において、映像のエンド間遅延は音声のエンド間遅延に比べて最大値と最小値の差が大きいが、これは映像が30fpsで処理されており、エンド間遅延の算出も1/30sec単位で行ったためである。また、図２５において、利用者端末１０の数が７と８の場合の音声のエンド間遅延は高いが、これは２台の共用端末１４０それぞれが、４台の利用者端末１４０による専用ミキサを動作させ負荷の高い状態になったことが音声の遅延に影響していると考えられる。一方、リップシンクについては、ITU-R勧告BT.1359-1（非特許文献１８参照）に記載されている許容範囲（音が映像より先の場合90ms、音が映像より遅れる場合185ms）を満たすことも確認できた。音が映像より遅れる時間は、音と映像の平均遅延値の差から、720pの実験において-31.1ms（利用者端末数2）〜11.8ms（利用者端末数６）であり、360pの実験では、22.2ms（利用者端末数３）〜62.3ms（利用者端末数７）であった。

実験を通し、cfg-3s（M shared terminals）の構成を利用する会議通話において、各利用者端末１０ではそれぞれ別の専用ミキサを利用できることが確認できた。720pの実験では、１台の会議サーバ１１０を用いた場合に参加可能な利用者端末１０の台数が２台であったのに対し、共用端末１４０の台数を増やすことで、その４倍の利用者端末１０間における会議通話が可能となった。また、360pの映像を用いた実験では、２台の共用端末１４０で８台分の専用ミキサを利用できることが確認できた。

6.4 実際の通信イベントにおける運用事例
本プロトタイプシステムにより、これまで２回の通信イベントを支援したので、運用事例として概要をまとめる。図２６Ａ、図２６Ｂは、それらのネットワーク概要を示している。

2014年3月7日に実施された「第5回地域防災情報シンポジウムでは、高知県立大学をメイン会場として岩手県立大学と静岡県立大学の3地点をJGN-X（非特許文献１９参照）とSINET4（非特許文献２０参照）]で繋いだ。図２６ＡにおけるAPはJGN-Xのアクセスポイントを示している。岩手県立大学内では会場が２つに分かれており、実質４地点間の会議通話を実施した。岩手県立大学に一時的なバックエンドシステム１００を準備し、１台の会議サーバ１１０と１台の共用端末１４０を用いて、映像にはcfg-2sの構成で共用ミキサを、音声にはcfg-3s（1 shared terminal）の構成を用いて地点毎の専用ミキサを適用した。映像には720pを用いたが、静岡県立大学側で使用帯域を抑える必要があったため、4Mbps（WMV CBR4Mbps）の映像ストリームを利用した。音声のキャプチャおよびストリームには評価実験と同じものを用いた。各会場ともに、持ち込み機材を中心としたイベント用の通信環境を用意する必要があったが、会場利用の都合により、機材のセットアップはイベント前日と当日に行われた。岩手県立大学側における前日(2014年3月6日)の準備は１時間で終了し、当日（2014年3月7日）、各会場間の通信テストや打ち合わせを含む3時間50分と本番4時間30分の間、システムを稼動させることができた。

一方、2014年5月28日に実施された「ICT推進フェア 2014 in 東北」では、仙台のメイン会場と高知工科大学および岩手県立大学の3地点を、JGN-Xを中心とするネットワークで繋いだ。一時的なバックエンドシステムは先の利用事例同様、岩手県立大学に用意した。１台の会議サーバ１１０を用いて、映像にはcfg-2の構成を、音声にはcfg-3の構成を適用した。映像は720pを用いたが、メイン会場のせんだいメディアテークにおいて使用帯域を抑える必要があり、映像には3Mbps（WMV CBR4Mbps）のストリームを利用した。音声のキャプチャおよびストリームには評価実験と同じものを用いた。この通信イベントでも、各会場ともに持ち込み機材を中心としたイベント用の通信環境を用意する必要があったが、先の例と同様、セットアップはイベント前日と当日に行われた。前日（2014年5月27日）、岩手県立大学側におけるバックエンドシステムの準備は40分で終了した。前日は、メイン会場におけるネットワーク接続の調整に時間がかかったが、ネットワークレベルの接続が完了してからは、本システムを用いて事前の打ち合わせを行うことができた。また、当日(2014年5月28日)の準備に2時間、本番3時間50分の間、システムを稼動させることができた。

これらの通信イベントの準備と本番において、会議通話へ支障を来たす通信トラブル等は無かった。しかし、特定の利用者端末における映像表示と音声再生の同期（リップシンク）に体感できるズレが生じることはあった。特定の利用者端末における音声再生モジュールにて、レンダリングバッファ内に音声データが少しずつ蓄積されることが原因である。通信イベント実施時には、その利用者端末において会議通話中の無音期間にレンダリングバッファ内の音声データをフラッシュすることによりリップシンクのズレを回避することができた。一方、現在のプロトタイプシステムには、映像と音声の完全な同期機能は実装されておらず、遅延時間を増やさずにリップシンクをとる機能の実装は今後の課題と考えている。

これら２つの通信イベントを通して、本プロトタイプシステムを用いて一時的なバックエンドシステムをイベント用のネットワーク上に用意し、通信イベントを支援することが可能であることを確認した。
6.5 機能的な考察
通信イベントへの適用を想定し、機能評価実験と運用の結果を踏まえて、提案システムと既存MCUを比較し、機能的な考察を以下にまとめる。

（１）HD品質の会議通話機能
現在、複数のベンダーから多くのビデオ会議専用システムが提供されている（非特許文献２１〜非特許文献２４参照）。ビデオ会議端末内蔵型のMCUの多くは４地点〜９地点間の通信を実現しており、１０地点間を接続できる内蔵型のMCUもある。一方、サーバ型MCUを利用すると、そのシステム規模に依存するが数１０地点間の通信も可能となる。実装したプロトタイプシステムでは１台の会議サーバ１１０を用いて、cfg-2の構成で８地点、cfg-1の構成で９地点間の通信が可能であることを実験結果から示した。また、必要となる帯域は利用するコーデックにも依存するが、プロトタイプシステムでは720pの映像を2Mbps程度でも転送可能であり、通信イベントのネットワーク環境に応じて調整することができる。１台の会議サーバ１１０におけるHD品質の会議通話接続数としては、平均的な内蔵型MCUと同等の地点数を汎用PCで実現した。

（２）バックエンドにおける機能分散
通信イベントの実施にあたり、複数の会議通話の同時実施や、地点毎に専用ミキサ機能を利用したい場合がある。高機能なサーバ型MCUには搭載されている機能であるが、一時的に集め易い機材を用いることを前提すると、高機能なサーバ型MCUの利用は困難であることが多い。一方、汎用PCを利用するという観点では、既存のソフトウェアMCUの適用も考えられる。ソフトウェアMCUも複数のベンダーから提供されているが、これらのソフトウェアMCUは、日常的なビデオ会議の利用を前提としており、バックエンド（１００）で会議サーバ１１０を常時稼動させることを想定している。そのプラットフォームには、Intel （登録商標）Xeon（登録商標）シリーズ等、主にサーバサイドで用いられる高性能なCPUが推奨されており、専用機としてのサーバ型MCU同様、一時的に準備するのは難しいことが想定される。

提案システムでは、汎用PCを用いた分散システムにより複数会議通話の実施に対応すると共に、複数の共用端末１４０を用いた分散型のミキサ機能も実現した。ミキサ機能のみを複数の共用端末１４０で分散する仕組みにより、利用するミキサの数に応じて機能を拡張できるバックエンドシステム１００が構築可能となる。サーバ型MCUを利用しなくとも、汎用PCを用いてこれらの機能を分散構成可能としたことは、通信イベント実施時の一時的なバックエンドシステム構築をこれまでより容易にするものと考えている。

（３）標準プロトコルへの対応
既存のビデオ会議システムにおける代表的な呼制御プロトコルはH.323とSIPであり、映像や音声データの送受信にはRTPやHTTPが多く用いられている。本システムのプロトタイプシステムは、現在これらの標準プロトコルに準拠しておらず独自のプロトコルを用いている。従って、既存のビデオ会議システムとプロトタイプシステムの互換は無い。一方、通信イベントの実施にあたり、既存のビデオ会議システムで利用されている標準プロトコルとの互換があれば利用可能な端末の種類や利便性の向上にも繋がるため、標準プロトコルの導入は今後の課題となる。

（４）その他の機能
既存のMCUには、会議のスケジューリング機能やストリーミング機能を搭載しているものもある。通信イベントを支援する上で、複数の会議通話の開始と終了を円滑に進めるためにスケジューリング機能は有効であり、通信イベント実施の様子を中継するためにはストリーミング機能が有効と考えられる。これらの機能については、引き続き既存技術を踏まえて実現を検討する。一方、ここで提案したストリームパスのパターンを組み合わせることにより、１つの会議通話の中でも、末端で利用可能な帯域幅に応じて会議通話地点毎に適切な品質の映像と音声を用いた通信が可能となり、利用者端末１０毎に共用ミキサと専用ミキサを使い分けるといった会議通話も可能となる。今後、通信イベントにおける利用を通して、ストリームパスのパターンの組み合わせについても有用性を検証する。

以上を踏まえ、ビデオ会議システムを提供している主要なベンダーの既存MCUと提案システムとの機能的な比較を表３に示す。必要に応じて会議通話数や専用ミキサの機能を、汎用PCを用いて拡張的に利用できるのは提案システムのみとなる。通信イベントの支援を想定し、そのイベントの主旨に応じて汎用PCで機能を拡張できる適合型の会議通話システムを実現したと考えている。

７．まとめ
ここでは、通信イベントにおける会議通話を支援するために必要となる通信システムの機能を整理し、通信イベントの主旨に応じて一時的に構築可能な会議通話システムについて述べた。通信イベントを支援する会議通話システムへの要件としては、（１）制約のある通信イベント用のネットワーク上で会議通話システムを一時的に構築できること、（２） ネットワーク環境に応じて映像と音声の中継機能とミキシング機能を適応的に構成できること、（３） 同時に実施可能な会議通話数を増やせる機能と、地点毎のミキシング機能を、必要に応じて拡張的に利用できることが挙げられる。これらの要件を満たすためには、既存のビデオ会議システムにおけるサーバ型MCUの機能の内、複数の会議通話を同時に実施する機能と地点毎のミキシング機能を通信イベント毎に適合させる必要がある。そこで、中継機能とミキシング機能を必要に応じて複数の汎用PCで分散させるためのプロトコルを設計・実装した。また、中継機能とミキシング機能を分散させるためには、適切なストリームパスを複数の端末で動的に構成する機能が必要となるので、会議通話で必要となるストリームの構成毎にストリームモデルを用意し、それを選択的に組み合わせることができるよう会議通話システムを実装した。

また、評価実験を通して、既存のHD対応型ビデオ会議専用端末を用いる場合と同程度の地点間における会議通話が実現できることを示し、同時に複数の会議通話を実施する機能と地点毎のミキシング機能を、複数台の汎用PCで分散処理することにより実現できることも示した。さらに、提案システムが実際に運用可能であることも２回の通信イベントの支援を通して確認できた。

今後は、プロトタイプシステムの実装における性能と機能の向上を図ると共に、実際の通信イベントでの利用を通し、より柔軟な運用を可能とする高機能な分散型会議通話システムの研究開発を進める。

以上、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。上述したこれら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (13)

1. それぞれ利用者が操作する複数の利用者端末と、
   該複数の利用者端末が通信ネットワークを介して接続されるバックエンドシステムとを有し、
   該バックエンドシステムの制御のもと、前記複数の利用者端末が映像データ及び音声データの前記通信ネットワークを介した送受により会議通話を行う会議通話システムであって、
   前記バックエンドシステムは、
   複数の中継部と、
   映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、
   前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して前記複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する制御部とを有する会議通話システム。
2. 前記バックエンドシステムは、
   前記複数の中継部及び複数のミキシング部を含むサーバ装置を有する請求項１記載の会議通話システム。
3. 前記バックエンドシステムは、
   前記複数の中継部を含むサーバ装置と、
   前記複数のミキシング部を含む端末装置とを有する請求項１記載の会議通話システム。
4. 前記バックエンドシステムは、
   前記複数の中継部を含むサーバ装置と、
   前記複数のミキシング部が分散配置される複数の端末装置を有する請求項１記載の会議通話システム。
5. 前記複数の端末装置のそれぞれは、前記複数のミキシング部のいずれか１つを含む請求項４記載の会議通話システム。
6. それぞれ利用者が操作する複数の利用者端末と、
   該複数の利用者端末が通信ネットワークを介して接続されるバックエンドシステムとを有し、
   該バックエンドシステムの制御のもと、前記複数の利用者端末が映像データ及び音声データの前記通信ネットワークを介した送受により会議通話を行う会議通話システムであって、
   前記バックエンドシステムは、
   複数の中継部と、
   映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、
   前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する第１制御部と、
   前記複数の利用者端末それぞれからの映像データまたは音声データを一または複数の中継部を介して前記複数のミキシング部において共用ミキシング部として決められたものに提供し、該共用ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して前記複数の利用者端末のそれぞれに向けて配信するよう制御する第２制御部とを有する会議通話システム。
7. 前記バックエンドシステムは、
   前記複数の中継部及び複数のミキシング部を含むサーバ装置を有する請求項６記載の会議通話システム。
8. 前記バックエンドシステムは、
   前記第１制御部の制御に係る複数の中継部及び複数のミキシング部を含む第１サーバ装置と、
   前記第２制御部の制御に係る複数の中継部及び共用ミキシング部を含む第２サーバ装置とを有する請求項６記載の会議通話システム。
9. 前記バックエンドシステムは、
   前記第１制御部の制御に係る複数の中継部を含む第１サーバ装置と、
   前記第１制御部の制御に係る複数のミキシング部を含む第１端末装置と、
   前記第２制御部の制御に係る複数の中継部を含む第２サーバ装置と、
   前記第２制御部の制御に係る前記共用ミキシング部を含む第２端末装置とを有する請求項６記載の会議通話システム。
10. 前記バックエンドシステムは、
    前記第１制御部の制御に係る複数の制御部を含む第１サーバ装置と、
    前記第１制御部の制御に係る複数のミキシング部が分散配置される複数の第１端末装置と、
    前記第２制御部の制御に係る複数の中継部を含む第２サーバ装置と、
    前記第２制御部の制御に係る前記共用ミキシング部を含む第２端末装置とを有する請求項６記載の会議通話システム。
11. 前記複数の第１端末装置のそれぞれは、前記複数のミキシング部のいずれか１つを含む請求項１０記載の会議通話システム。
12. 映像データ及び音声データの通信ネットワークを介した送受により会議通話を行う複数の利用者端末と前記ネットワークを介して接続され、前記会議通話を制御するバックエンドシステムであって、
    複数の中継部と、
    映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、
    前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して前記複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に向けて配信するよう制御する制御部とを有するバックエンドシステム。
13. 映像データ及び音声データの通信ネットワークを介した送受により会議通話を行う複数の利用者端末と前記ネットワークを介して接続され、前記会議通話を制御するバックエンドシステムであって、
    複数の中継部と、
    映像データ及び音声データのそれぞれを合成して映像及び音声それぞれのミキシングデータを生成する複数のミキシング部と、
    前記複数の利用者端末のそれぞれに前記複数のミキシング部のいずれかを対応づけ、前記複数の利用者端末からの映像データまたは音声データを複数の中継部を介して複数のミキシング部に提供し、各ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して対応する利用者端末に配信するよう制御する第１制御部と、
    前記複数の利用者端末それぞれからの映像データまたは音声データを一または複数の中継部を介して前記複数のミキシング部において共用ミキシング部として決められたものに提供し、該共用ミキシング部にて生成される映像または音声のミキシングデータを一または複数の中継部を介して前記複数の利用者端末のそれぞれに向けて配信するよう制御する第２制御部とを有するバックエンドシステム。