A Distributed Architecture of Video Conference Using P2P Technology

Transcription

1 1852 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER 2012 A Distributed Architecture of Video Conference Using P2P Technology Xiaoyan Yu State Key Laboratory of Networking & Switching Technology Beijing University of Posts and Telecommunications (BUPT), Beijing, China, [email protected] Zhenyu Yu State Key Laboratory of Networking & Switching Technology Beijing University of Posts and Telecommunications (BUPT), Beijing, China, [email protected] Abstract Most of the traditional video conferencing are standard SIP or H.323 architecture. There will be a single point of performance bottlenecks if large-scale video conference or a larger number of conferences emerge at the same time. In this paper, we proposed a new architecture of Multipoint Video Conference which can support a lot of meetings simultaneously using P2P and application multicast technology. In the side of server, the component called Media Control Server (MCS) is responsible for the media data process and transmission path selection. All the MCSs form the MCS overlay. The capacity and conference state information of User Equipments (UE) are stored in the MCS overlay. MCSs which be selected process all the transcoding and transmission task of audio and video for a meeting. In the side of user, some UEs which have enough bandwidth or other conditions could also undertake parts of media data process. MCS that service to the first UE in a conference decides which audio media process task could be assigned to Conference UEs; video media process task is allocated by Service MCS of video source. There are several methods to decide the transmission path, such as delay by server, application layer multicast or Hungarian method. At last, analysis is given to demonstrate the effectiveness of our architecture. Index Terms P2P, Video conference, Hungarian method I. INTRODUCTION Multipoint video conference system is the remote virtual meetings realized by modern communication technology. It exchanges information through image, sound and other media, so that geographically dispersed users can exchange remote real-time information and work cooperatively. With the development of network technology, multimedia conferencing system has been used widely. Traditional multipoint conference system is based on the C/S structure, and needs to configure dedicated server to achieve conference control and media processing. MCU server, which is the key equipment of multimedia conferencing system, completes the audio mixing or switching, video mixing or switching, media data distribution, conference control. MCU sent various kinds of information flows to each meeting node. However, there are some limitations in traditional scheme as follows. First, server performance bottlenecks: in the C/S mode, MCU server will be responsible for audio and video data processing for conference terminal. Because the media processing often need to consume a lot of hardware resources, resulting in a single MCU server performance and capacity limited, it s only support a limited number of users online simultaneously. Second, large bandwidth requirement: most current multimedia systems require high bandwidth, because the audio and video transmission of each conference terminal requires the server to support. To ensure conference quality, MCU server bandwidth required to ensure adequate and better stability. While large number of meetings at the same time, the server's bandwidth would be a big burden. Third, few access methods and device types: most of the current solution based on dedicated hardware device, PC or phone access. With the development of networks and devices, set-top boxes, smart phone using wireless access, MID and other types of terminals will bring new user experience and needs, and the convenience and ubiquitous user experience can be realized. From all the points discussed above all, traditional video conferencing architecture has its inherent drawbacks. So we designed a novel system using distribution technology. We enhanced performance in two ways: all the MCS servers form the MCS overlay in the side of server; MCSs select the UE with enough bandwidth commitment to media delivery task in the side of user. In this paper, the video conference platform is suitable for the following scenario. It could be run by operator and support many meetings simultaneously; for a single meeting the number of participants is relatively small. Considering the above scenario, the scheme of traditional video conference system need deploy many servers to process media data, a very high cost. Therefore, we doi: /jnw

2 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER introduced the Distributed Conference Media Processing. On the basis of traditional software video conferencing, our project makes full use of UEs to undertake parts of the task of audio and video processing to reduce the server bandwidth and hardware resources cost. To take full use of UE(bandwidth, CPU, memory) while ensuring QoS, the program described in this article effectively combine the two through specific mechanisms and algorithms. Server and UE assume the function of coding and forward together, but conference organization task is only assumed by the server. The rest of the paper is organized as follows. The related works are discussed in section II. The novel architecture is presented in section III, including system architecture and media distribution operations. Media process mechanism is introduced in section IV. We analyze the performance in section V, comparing the new architecture with traditional conference system. Finally, the conclusion is drawn in section VI. II. RELATED WORK The emergence and development of video conferencing technology gradually changed the modern social life. With the rapid progress of related technologies, video conferencing systems are constantly evolving. Now the mainline system architecture can be divided into three categories: Centralized, Layered, Full-distributed. Centralized architecture is the classic architecture, including SIP-based, H.323-based and video control server-based. Centralized architecture has a problem cannot be avoided - single point of performance bottlenecks. Hardware and software conditions are fixed; the number of users it supports must not change. At the same time once the server failure, all the meeting it manages was terminated, so centralized architecture is not conducive to system stability. In small scale video conferencing, single MCU can satisfy the requirement, but it must be cascaded with a number of MCU to adapt to large-scale [1]. MCU is divided into the master server and the slave server: the master server is responsible for conference management, slave server of assignment; the slave server is responsible for media processing; media data to be exchanged between slave servers. However, requirements of this structure to master and slave server are very high and it is not flexible enough. It must expect the population of users, and arranged the server accordingly. Therefore, the cost is also very high, and it may be congestion like the traditional centralized system. With the growing processing power of the terminal, there has emerged distributed architecture of the video conference. Chong Luo etc, Microsoft Research Asia published DigiMetro [2] described a multicast tree building program, which each members have equal status, each maintain its own multicast tree according to periodic probing delay and bandwidth. But this program does not take into account the dynamic nature of conference members. The departure of intermediate nodes in the multicast tree leads his child and grandchild cannot receive audio and video normally. This scenario may cause some users can not access to the conference. At the same time, because the ability of UE is limited and not guaranteed, the system's QoS is not guaranteed. S.Nari, H. R. Rabiee etc, proposed an application-layer multicast protocol for a small-scale video conferencing system [3]. Heuristic routing algorithm is used to carry out efficient application layer multicast tree construction. This program has a better performance in the rejection rate, while meeting the QoS constraints, end to end delay and bandwidth requirements of video conferencing applications. But consideration of the node exit is not consummate; especially failure of intermediate nodes is not taken into account. In this paper, we proposed a new distributed architecture for both server side and user side, which take account to make full use of user terminal processing power and guarantee the quality of video conferencing. III. SYSTEM OVERVIEW A. Architecture Figure 1 depicts the network architecture based on MCS overlay which consists of a set of cooperating peers. MCS is responsible for the process of media data. UE can execute the conference operation such as create, join and leave. Each UE is a client for the MCS overlay. According to the scale of UEs, there may be many MCSs in system. The capacity and state information of UEs is stored by Owner MCS in this overlay. We use DHT algorithm to find and route between MCSs, such as Chord [4], Kademlia [5]. Each MCS have only one identity and adopt Reload [6] protocol to look up each other. The main functions of the core network are provided by the overlay in which the peers can efficiently route messages to other peers and store and retrieve conference information. Conference Control Server (CCS) handle UE online state and other conference functions such as instant message and it will assigns suitable MCS to UE when they join a conference. We call the suitable MSC Service MSC. There is only one Conference Database (CDB) in system. CBD stores and maintain conference and UE s static information, IP address and location information of each MCS in the system. CCS and CDB is the system manager, and CDB is a centralized user database. CCS assigns a Service MCS to every UE, which is responsible for handling the UE's media request. In addition, UE in different network may be assigned to different MCS to access. The MCSs will be deployed in different networks too, So that the system will choose a proximal MCS for the UE.

3 1854 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER 2012 Figure 1. System Architecture B. Scenario and Procedure UE set the conference name, type, the number of participant and other information, then sent conference creation request to the CCS. This information will be stored in CDB. Participate in a conference Figure 3. Measure and report In this scene, assuming that and have already joined in the meeting, is a new entrant and its service MCS is MCS2. get the UE list of the same conference and need to detect its own status and measure the delay between other UEs and itself, and then stored them in the Owner MCS. will detect its own state parameters including: CPU capacity is defined as UE_CPU, the memory capacity is defined as UE_Memory, uplaod bandwidth is defined as UE_UpBW, download bandwidth is defined as UE_DownBW, video bit rate is defined as the UE_BitRate (bit), delay between itself and other UEs: UE_Delay. UEs which have joined in a meeting need to detect some parameters when new UE join or detect periodically. Leave a conference Figure 2. Participate in a conference sent the join request to CCS. The request should contain the conference ID. CCS takes the conference ID as keyword to request the relative data from CDB. According to the information returned by the CDB, CCS will choose a proper MCS as UE s Service MCS based on geographical information. Then CCS update the relative information, including the MCS that service for the same conference and the number of UE serviced by each MCS, also including UEs that has joined in the same conference. receive the assignment result, and then establishes a connection with his service MCS. At the same time, UE measure performance parameter and store it to the Owner MCS by DHT Algorithm like Chord. State measurement and reporting Figure 4. Departure form a conference When exit from conference, it must delete the relative item stored in overlay and CDB server. IV. MEDIA PROCESS MECHANISM A. Audio Stream Process In the distributed conference platform, audio streams of UEs could be mixed together and then transmitted to each UE, which is optional. If capable UEs exist, one of them will be selected to mix the audio streams. The MCS server assigned to UE who is the first to join the conference will be responsible for the decision of audio streams mixing selection. The determination should incorporate with bandwidth, CPU ability and other conditions. If there is no suitable UE to be selected The MCS server will be responsible for audio mixing itself.

4 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER When the mixing node failed for some reasons, the MCS server will take over the task or choose new UE to continue. Audio Stream MCS1 notices is the mixer ACK MCS2 informs MCS1 joined Inform is the mixer Inform is the mixer Re-Computing the Audio mixer Get information Performance information Figure 5. Selection of audio-mix peer in a Distributed Conference In Figure 5, joined in the conference which and have already joined. MSC1 is responsible to decide the proper UE to undertake the audio mixing task. In the first phrase there is no UE selected as mixing node, so MSC1 will be responsible for audio mixing. registers in the conference and stores its information to the overlay through MCS2; MCS2 informs MCS1 that a new node joined in the conference; MCS1 fetches current UE list from overlay which include the ability information of all UEs; After check of node capacity MCS1 find could be selected as mixing node. MCS1 will notice the selection result. gives acknowledge response; MCS1 informs and the new audio mixing node is ; and will send their audio stream data to. After selecting the audio mixer, all the UEs sends their own audio stream data to the mixer, the mixer node completes the mixing of different audio streams and then sends to all the other UEs. B. Video Stream Process Video stream processing is different from the audio stream processing. Video stream handling requires more resources than audio transmission, such as CPU ability and bandwidth. For this section, When wants to watch the video of UE0; UE0's MCS is responsible to choose the transmission path according the UE capacity information stored in the overlay. Then UE0's MCS informs and UE0 the transmission path and UE0 starts transmit video stream. Figure 6. Video steam transmissions in a Distributed Conference In Figure 6, MCS1 serves, MCS2 serves and. The owner MCS stores the conference information. wants to watch 's video and sends request to its service MCS1; MCS1 asks Owner MCS through certain route policy for 's Service MCS information. Owner MCS gives a response that MCS2 is the Service MCS of, MCS1 sends request to MCS2; MCS2 checks suitable video transmission path and find could be the relay node to transfer video stream; MCS2 informs the result to, and ; starts sending its video stream to and transfer it to. The video stream transmission mode from one node to another can be classified 3 kinds. Figure 7 shows the different cases of video transmission. Figure 7. Different Video Stream Transmission modes In this scenario, wants to watch s video. The video steam can be transmitted in 3 ways: Mode 1: When two UEs are in the same LAN or their network conditions can satisfy the requirement of the delay and bandwidth. The clients can be connected directly. can send its own video stream directly to without the help of other node. Mode 2: When two UEs can't send video stream directly, MCS will try to find another UE to transfer the video stream. If MCS1 find the node, then 'll send the stream to and transfers the stream to. Mode 3: If no UE can be found, MCS will undertake the process task. transfers its video stream to MCS2, MCS2 forwards the video stream to 's server MCS1. Finally, MCS1 sends video stream to. In order to save the resource of server as much as possible, method 1 and method 2 have a higher priority to be used. In addition, UE may need to send its video stream to several other UEs for watching in a meeting. In order to make full use of the media transmission ability of UE node, an appropriate transmission model should be constructed, such as Tree-based model and Mesh-based model. The construction of the model should incorporate bandwidth, CPU ability, delay and other conditions, but

5 1856 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER 2012 the details still need to be further studied. Figure 8 gives an example of Tree-based transmission model. Figure 8. Tree-based transmission models In the Tree-based model, the video source node, as the root of the tree, is responsible to construct and maintain the video multicast tree. Three aspects should be considered: First, the more capable the peer is, the lower the level it is. This ensures the powerful peers take the most jobs. The methods may include election [7] or some other multicast algorisms. Second, the level of the tree maybe kept as low as possible to ensure the reality of the conference. Third, the tree should be stable enough to ensure the continuity of the conference.. How to construct the multicast tree need to be further studied. In some cases, UE would like to watch several peers video stream while its bandwidth is not enough for the video transmission. Therefore, different video stream need to be mixed together firstly, then forward to the destination. To find a proper mixer peer, lots of conditions should be considered, especially chip ability. The details still need to be further studied. If selected node failed, the service MCS server will take it over or select new UE to undertake the task. C. Media Processing Task Assignment Algorithm based on Hungarian Method Assignment problem The assignment problem is one of the fundamental combinatorial optimization problems in the branch of optimization or operations research in mathematics. It consists of finding a maximum weight matching in a weighted bipartite graph [8]. In its most general form, the problem is as follows: there are a number of agents and a number of tasks. Any agent can be assigned to perform any task, incurring some cost that may vary depending on the agent-task assignment. It is required to perform all tasks by assigning exactly one agent to each task in such a way that the total cost of the assignment is minimized. The Hungarian method is a combinatorial optimization algorithm which solves the assignment problem in polynomial time and which anticipated later primal-dual methods. It was developed and published by Harold Kuhn in 1955, who gave the name "Hungarian method" because the algorithm was largely based on the earlier works of two Hungarian mathematicians: Dénes Kőnig and Jenő Egerváry [9]. Media processing task assignment algorithm Hungarian method can be applied to allocate the media processing task in distributed multimedia video conferencing to obtain the optimal scheme. It makes the sum of the media transmission delay to minimum at the same time. Parameter definition Assumed that there are n terminals in a video conferencing system, and numbered each terminal from to UEn: x is the terminal number. The CPU capacity of each terminal is defined as UECPU (x), the memory capacity is defined as UEMemory (x), uploading bandwidth is defined as UEUpBW (x), the downloading bandwidth is defined as UEDownBW (x), the video bit rate is defined as BitRate (x), delay between any two terminals define as delay (x1, x2); Owner MCS collect all the UE status information, as well as media requests, and perform the task assignment algorithm. Assignment algorithm details i. Media communication is described as the following mode: when conference terminals request media data for other nodes, server makes a request description table according to the requester index. The following picture describes the relation of media request at a certain time. Figure 8. Media relation Description table is as follows: Receiver UE5 TABLE I. TASK DIVIDED BY RECEIVER Sender UE5

6 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER Take the receiver as index to deal with TABLE I. The result is TABLE II. ii. iii. iv. TABLE II. TASK DIVIDED BY SENDER Task number Sender Receiver Task 1 Task 2 UE5 Task 3 Task 4 Task 5 UE5 Calculate according to TABLE II The required resource list: CPU (x) MEMORY (x) Outband (x) Inband (x). TaskCPU TaskMemory is determined by the experience; TaskOutband = BitRate of resource * the number of receiver; TaskInband = BitRate of resource. When each task processed by different nodes, TaskDelay (x) is calculated as follows: TaskDelay = Delay (task node, resource node) + Max (Delay (task node, request node)). According to the resource request list, find out the maximum resource requirements for each task: MaxTaskCPU,MaxTaskMemory, MaxTaskOutband, MaxTaskInband. Select a node which meets the four qualifications from the node list. Suppose a total of n nodes are selected. If a node is selected while it requests the same video data, it should be reduced the MaxTaskOutband requirements for the task. Assumed that there is m tasks in system: If n >= m, solve the problem according to Hungarian method that number of persons is more than number of tasks [10]. If n < m,solve the problem according to standard Hungarian method for the first n tasks in the task list. The rest m n tasks loop to step iii, iv until all tasks are allocated. Calculate the candidate node for task in the table of resource requirements. When network status changes, reconstruct Table I and Table II, and loop the steps i ii, iii, iv. A example UECPU (Hz) TABLE III. PERFORMANCE OF NODE UE5 1.2G 1.6G 1.6G 2.2G 2.0G UEMemory (MB) UEUpBW (bit) 2M 1M 5M 2M 2M UEDownB W (bit) BitRate (bit) Delay (x1,x2) ms 4M 2M 10M 4M 4M 300K 300K 300K 300K 300K TABLE IV. DELAY BETWEEN ANY TWO NODES UE UE TABLE V. TASK DIVIDED BY RECEIVER Receiver Sender Code information TABLE VI. TASK DIVIDED BY SENDER Task number Sender Receiver Task 1 Task 2 UE5 Task 3 UE5 UE5 UE5 Task 4

7 1858 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER 2012 TaskCPU (Hz) TaskMemo ry (MB) TaskOutba nd (bit) TaskInband (bit) TABLE VIII. Task 5 UE5 TABLE VII. REQUEST OF RESOURCE Task 1 Task 2 Task 3 Task 4 Task 5 1G 1G 1G 1G 1G k 300k 600k 600k 300k 300k 300k 300k 300k 300k COST OF TASK PERFORMED BY DIFFERENT NODES ms UE5 Task Task Task Task Task The results of the Hungarian method are as follows: Task3 Task1 Task4 Task5 UE5 Task2 V. PERFORMANCE ANALYSIS In traditional centralized multipoint video conferencing architecture, scalability depends on the hardware of single server, such as CPU, memory, bandwidth. The novel system architecture we mentioned in this paper makes full advantage of the ability of user terminals, thus it improves the video conferencing system scalability greatly. Compare with CPU and memory, the current network bandwidth resources are scarcer. We simply analyze the different needs of two different systems from the bandwidth point. Suppose there are Np participators in one conference, at the same time the number of conference in this system is Nc, each session can have Ns individuals provide the video stream, video bitrate is Ms, U is the update bandwidth of an UE. It requires the server to provide Np Nc Ns Ms in classic centralized system architecture. If use the novel system mentioned in this article, a part of bandwidth requirement for forwarding video stream is provided by UEs, so the server reduce the bandwidth required significantly. We assume that UE make full effort to help forward the video stream. Under the same condition, it needs N N N M U N N p c s s p c. Learning from the above formulas, distributed video conferencing system can reduce server bandwidth pressure significantly. There are many MCSs in our system, and each UE can choice the closest one to access. If link conditions between two UEs meet the demand, direct connection will be choice to reduce the number of media forwarding. If the direct link between the UEs is poor, the UE in the same conference or the Service MCS will be used to relay. Compared with traditional architecture, the above three methods guarantee real-time transmission of video media in the case of taking advantage of terminal capacity. VI. CONCLUSION AND FUTURE WORK The multipoint conferencing constitutes a critical application for Internet. Audio, video and other type of media can be distributed efficiently between conference groups using P2P algorithms. This paper proposed a novel architecture and media delivery solutions. In server side, we take the distributed routing algorithm to maintenance the relationship. It is highly scalable, high reliability. At the same time, we make the full-use the CPU and bandwidth resources of the UEs to reduce server resource consumption in media transmission scheme. On the one hand, this system supports a lot of clients in single conference. On the other hand, it supports the larger number of conferences exist simultaneously. In the next research, we will focus on further optimization about transmission scheme; LAN multicast [11] is an optional way. ACKNOWLEDGMENT This work is partially supported by Research Fund for the Doctoral Program of Higher Education of China ( ); National Key Basic Research Program of China (973 Program) (2009CB320504); Important national science & technology specific projects: Next-generation broadband wireless mobile communications network (2010ZX ). REFERENCES [1] Zhifeng Qin, Research of Key Technologies for P2P Video Conference System, [2] C. Luo, J. Li, and S. Li. DigiMetro An Application-Level Multicast System for Multi-party Video Conferencing. Microsoft Research Asia, Jun [3] Nari, S. ; Rabiee, H.R. ; Abedi, A. ; Ghanbari, M. An Efficient Algorithm for Overlay Multicast Routing in Videoconferencing Applications. Computer

8 JOURNAL OF NETWORKS, VOL. 7, NO. 11, NOVEMBER Communications and Networks, ICCCN Proceedings of 18th Internatonal Conference. [4] Stoica I., Morris R., Karger D. R., et al. Chord: A scalable peer -to-peer lookup service for Internet applications. IEEE/ACM Trans. Networking, [5] Maymounkov P., Mazieres D.. Kademlia: A peer-to-peer information system based on the xor metric. In Proc. International Peer- to-peer Symposium, pages 53 65, Cambridge, MA, USA, March [6] C. Jennings, B. Lowekamp, E. Rescorla, H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol" October 29, [7] Liu Zhenxiang, Liu Song, Shi Yongheng. The Hybrid P2P of Video Teaching System Design. International Conference on Multimedia and Signal Processing, [8] Bai Guo zhong. B-assignment problems [J].Journal of systems Science and Systems Engineering, [9] HW Kuhn. The Hungarian method for the assignment problem. Naval research logistics quarterly, [10] Qionghua Wang, Gang Wang. A solution to the modeling of assignment problem: the Hungarian way. Journal of Kunming Metallurgy College, Sep, [11] HaiYan Liu, Zhiyuan An, Audio-Video conference systems Design and Implementation base on P2P and Multicast. Electronics, Communications and Control (ICECC), International Conference Xiaoyan Yu is a researcher in State Key Laboratory of Networking & Switching Technology. He has worked in a number of State projects. Her current research interests include switching technology, next generation network and distributed computing. Zhenyu Yu is a Master student in Computer Science at Beijing University of Post and Telecommunications. He received the B.S degrees from the PLA Information Engineering University in His research interests lie in overlay networks, P2P technology and telecommunications core network.