IMS-based distributed multimedia conferencing services for Next Generation Mobile Networks

HAL Id: hal-01260096

https://hal.archives-ouvertes.fr/hal-01260096

Submitted on 21 Jan 2016

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

IMS-based distributed multimedia conferencing services

for Next Generation Mobile Networks

Tien Anh Le, Hang Nguyen, Noel Crespi

To cite this version:

Tien Anh Le, Hang Nguyen, Noel Crespi. IMS-based distributed multimedia conferencing services for

Next Generation Mobile Networks. EURASIP Journal on Wireless Communications and Networking,

SpringerOpen, 2013, 2013:170, pp.1 - 17. �10.1186/1687-1499-2013-170�. �hal-01260096�

IMS-based distributed multimedia conferencing services for Next Generation Mobile

Networks

Tien Anh LE, Hang NGUYEN, Noel CRESPI1,1,1

a_{Institut Telecom - Telecom SudParis - 9 rue Charles Fourier - 91011 - Evry - FRANCE}

Abstract

Distributed architecture offers many advantages compared to centralized architecture in terms of providing multimedia services. However, as a trade-off, distributed architecture requires that peers contribute a portion of their bandwidth and computational capacity to maintain the mutual overlay inter-connection. This requirement develops into a serious problem for mobile users and wireless infrastructure, as the radio resource in this network is tremendously expensive, and is one of the reasons why distributed architecture has not been widely applied in next generation (4G) networks. It is also the main reason why multimedia services such as video conference have to rely on a costly centralized architecture built over an expensive Media Resource Function Controllers (MRFC) via the IMS (IP Multimedia Subsystem). This research work proposes a new distributed architecture utilizing intelligence and extra capacity, currently available on LTE and WiMAX’s Base Stations to reduce the required bit-rates that each peer has to provide in order to maintain the overlay network. This reduction saves valuable radio resources and allows a distributed architecture to provide video conferencing services on 4G networks, with all the advantages of a distributed architecture such as flexibility, scalability, smaller delay and lower cost. In addition, this can be impemented with a minimum modification of the standardized IMS platform and the 4G infrastructure, thereby saving the operators and service providers from excessive investments. A prototype has been built to prove the feasibility of the proposed architecture and evaluate its performances. The results show that our proposed distributed video conferencing service can actually reduce the average bandwidth required for data and signaling messages at wireless mobile terminals while maintaining the main operations of a video conference session.

Keywords: distributed video conference, service architecture, distributed architecture, overlay network, P2P, IMS, LTE, WiMAX, NGN, ALM, 4G

1. Introduction

Video conferencing service is the most complex type of mul-timedia communication. There are two main types of video conferencing service architectures: centralized architecture us-ing Multipoint Control Units (MCU) and distributed architec-ture using a multicast mechanism. Centralized architecarchitec-ture has many disadvantages, such as cost (incapable of decreasing the Capital Expenditures (CAPEX) or of lowering Operational Ex-penditure (OPEX)) or a very high level of delay - especially when the number of participants increases, the lack of flexibil-ity and scalabilflexibil-ity, and a single point of failure.

More specifically, when more participants want to join a video conference (e.g. at big events), the cost of a centralized archi-tecture increases sharply. Therefore, distributed archiarchi-tectures is foreseen to be the future of video communication service. Skype, a peer-to-peer (P2P) VoIP client developed by KaZaa in 2003, has so far the most popular Internet-based video confer-encing service. This application is able to throttle its sending rate to match the unpredictable Internet bandwidth while pre-serving resources[1]. Like its file sharing predecessor KaZaa, Skype is an overlay peer-to-peer network. There are two types of nodes in this overlay network, ordinary hosts and super nodes (SN). An ordinary host is a Skype application that can be used to place voice calls and send text messages. A super node is

an ordinary host on the Skype network[2]. Its main limitation is that the ”super node” architecture requires an infrastructure, similar to a CDN (Content Delivery Network), to be built and maintained in order to provide the video conferencing service. Moreover, as a commercial production, all its architectures and protocols are closed-source which leads to many difficulties for the research community in their attempts to improve Skype’s performance. Spiers et. al.[3] implemented IP multimedia sub-system (IMS)-based Video Conference sub-systems with two dif-ferent architectures, Server/Client and P2P, and measured their signaling and data traffic overhead. Their results showed that Server/Client offers better network control together with a re-duction in signaling and media overhead, whereas P2P allows flexibility, but at the expense of higher overhead. Another sys-tem, Nefsis, provides dedicated cloud computing resources for video conferencing. Users automatically connect to geograph-ically close servers distributed on the Internet to have a low-latency experience[4].

The MCU centralized architectures act as a single-point recip-ient for each participant, thus requiring a large bandwidth con-nection just only for itself. It prepares a Multi-Point video representation that can fit into a smaller bandwidth and sends it to each participant. However, because of the complexity and cost of the operating of the MCUs, they are mostly used

by large business applications that can afford such equipment. They also suffer from single-point-of-failures and hence are not failure transparent. A distributed architecture needs no special hardware or network infrastructure. Its P2P architecture pre-vents single-point-of-failures and provides failure transparency. There is no additional networking and computing resources needed at the end points other than that of a point-to-point video conference[5]. In terms of delay performance and required computational capacity, distributed architecture out-performs its centralized counterpart as shown in [6]. The quality of video content transmitted over the specifically designed overlay net-work has also been proved to be better than that of centralized architecture, using objective quality evaluation methods[7]. One of the main reasons why distributed architecture has not been widely applied in the wireless networks is that it increases the required bit rates at mobile terminals and within the net-work. Indeed, in mobile wireless networks, bandwidth is a very costly and limited resource. Therefore, it is almost impossible (for users) to apply directly the basic distributed architecture in mobile networks (due to the extra requirements in bit-rates, mobile terminals’ battery life, computation and the wireless re-sources for maintaining the overlay structure). To date, the mo-bile network and services have only been based on a centralized architecture. Almost no work has been found for distributed video conferencing service on mobile networks.

Recently, mobile participants have been equipped with high computational devices using radio access networks (e.g. 4G: Long Term Evolution, WiMAX), bigger screen sizes and better computational capacity. Real time multimedia services (such as video conference, video streaming) are foreseen to be ”killer”-applications on 4G. It is expensive and difficult to provide such services based on a centralized architecture. However, the dis-tributed video conferencing service architecture and the 4G net-work architecture have been designed separately without con-sidering the other’s requirements. Therefore, it is currently also difficult to provide real-time multimedia services based on a distributed architecture over 4G networks.

4G networks rely on the IP Multimedia Subsystem (IMS[8]) to provide multimedia services including video conferencing. In turn, the IMS-based video conferencing service is built and standardized for MCU-based or centralized service architec-ture. Therefore, it shares many similar problems with the cen-tralized video conferencing service architecture[7], especially when the number of User Equipment (UE) units that participate in the conference via the 4G infrastructure increases.

This research work proposes a solution for a distributed archi-tecture that allows the reduction of bit rates required by peers to save their valuable radio resources and make the distributed ar-chitecture possible for next generation mobile networks. In this research work, the LTE/WiMAX network is used as a demon-stration of a 4G infrastructure.

Due to the many advantages of the distributed architecture over the centralized architecture, the main purpose of our research is not to compare it with the centralized architecture. That is out of the scope of this research and we leave it to the many other ongoing research projects. Our purpose is to enable the dis-tributed architecture video conferencing service for next

gener-ation mobile networks with slight modificgener-ations of the 4G in-frastructure and of the IMS platform. To enable the distributed architecture to function over a mobile network, we have to solve the crucial problem of the high bit-rates required at the wireless terminals. In our solution, we will try to overcome this main disadvantage of the distributed architecture, which is why we will evaluate the performance of our proposal in terms of bit-rates for data and signaling plans.

A new solution is proposed here, which makes it possible for the current IMS-based LTE/WiMAX infrastructure to seam-lessly support distributed video conferencing services. The main contributions of the research are to:

• Propose an IMS-based architecture that supports LTE/WiMAX’s UEs and WiMAX’s SU to participate in distributed scalable video conferencing service without us-ing a centralized MCU. It significantly reduces the bit-rates required at mobile terminals, thus conserving the wireless resources,

• Develop a proof-of-concept prototype to prove the fea-sibility and compatibility of the newly proposed solution and

• Evaluate the performance of the proposed system under audio and video conference working scenarios.

Our proposed architecture’s requirements call for:

• New SIP messages and some standard ones with modifi-cations for new functionalities, new purposes and in new contexts in their destinations and content,

• A minimum modification of the 4G’s BS(s), • New xAS features.

The rest of the paper is organized as follows. In section 2, the 3Gpp’s standard for IMS-based video conferencing service will be introduced. Section 3 introduces our proposal for the IMS-based distributed video conference service and shows how it en-ables a distributed service architecture to be utilized over wire-less networks without increasing the radio resource require-ments. In Section 4, a prototype is constructed and the per-formance results are evaluated. We present our conclusions in section 5.

2. 3GPP IMS-based conference architecture

Figure 1 shows the 3Gpp standard architecture for the IMS-based conference architecture. Here Session Initiation Protocol (SIP) and Real-time Transfer Protocol (RTP) are used as the main signaling and media transportation protocols. The Call Session Control Functions (CSCFs) are entities that route SIP messages. The media gateway (MGW) is the entity that han-dles/forwards RTP traffic down to the UE when necessary. The conference focus is in both the Media Resource Function Con-troller (MRFC) and in the conferencing AS. The MRFC pro-vides all of the media related functions (e.g., mixing, transcod-ing, trans-rating...) required for conferencing. It may also

Figure 1: 3Gpp IMS conference architecture[9]

contain a Floor Control Server (FCS) function. Floor control is the term for managing the system according to user status (in/out/pause/return) and conference status (active users, chair-man). Since all of the media related functions for conferenc-ing are done in the MRFC, this architecture is highly central-ized. To overcome the disadvantages of the centralized ar-chitecture, a number of concepts have been proposed to sup-port distributed conferencing service architecture on the current centralized architecture of IMS-based conferencing services on LTE/WiMAX networks. One example proposes that the FCS feature is proposed to be separated from the MRFP[10]. That modification, however, that does not change the centralized na-ture of the architecna-ture. In another effort[11], a distributed solu-tion is proposed as an overlay network of centralized conferenc-ing clouds. However, that architecture would not provide for a proper integration with any specific overlay algorithm. More-over, even-though a Content Distributed Network (CDN) with proxy servers has been constructed to support this integration, clients still have to process all of the signaling and media loads. The proxy servers mainly serve as proxy MCUs to connect sev-eral clients together using a centralized architecture and then connect all of those centralized groups together by creating an overlay of proxy servers.

To conclude, the conventional methods for IMS-based video conferencing services are either centralized (in one form or an-other) or they have not fully utilized the capacity of the 4G in-frastructure.

3. Proposed IMS-based distributed video conferencing ser-vice

As a many-to-many communication mechanism, distributed video conferencing services are mainly built on multicast systems. IP-multicast[12] is the most efficient type of multicast today. However, its problems with deployment are preventing it from being widely applied[13]. The Application Layer Multicast (ALM) infrastructure is a promising alternative. Many ALM algorithms have been proposed and distributed video conferencing services have been built using ALM[14]. The problem is that, since ALM algorithms work on the application layer, there is no preference as to what kind of access network is used by the session terminals when they participate in a conference. In fact, many participants use

a radio access network (such as LTE or WiMAX [15]) to participate in conference sessions. Thus, limited and expensive resources of the mobile terminals and of radio channels are sometimes unnecessarily expended by ALM’s required operations such as heart-beating and data forwarding. While distributed conferencing service architecture can overcome many of the technical limitations of centralized architecture, the business model of the distributed conferencing architecture can create a win-win service for participants in which they can contribute their computation and get a free service in return (or they can even contribute their computation for their direct financial gain). At the same time, the distributed architecture can still support the existing business model that is provided by the centralized architecture. Our proposal to overcome these limitations has been partly presented in [16].

3.1. Inter-connectivity with LTE/WiMAX networks

A LTE/WiMAX system applies a ring-topology[17] where components connect together using the same core network. All eNodeBs in LTE/WiMAX systems are smart Base Station Sys-tems (BSS) built with built-in intelligence and are capable of contributing computational capacity to the service[18]. If these eNodeB/xBS can represent UEs in handling ALM data traffic forwarding and control message processing, UEs can partici-pate in the distributed conference as if they are participating in a conventional IMS-based centralized conference. The pos-sibility of deploying our proposal onto a LTE/WiMAX infras-tructure is discussed in this research work[19].

WiMAX is a broadband wireless access (BWA) technology for wireless metropolitan area networks. It has been fostered by the WiMAX Forum, an international industrial organiza-tion founded in June 2001 to promote the adoporganiza-tion of WiMAX compatible products and services[20]. A WiMAX network usually contains the following network entities[20]: an ASN (Access Service Network), a CSN (Connectivity Service Net-work), an ASP (Access Service Provider) and an MS/SS (Mo-bile station/Subscriber station). The ASN provides radio ac-cess to WiMAX subscribers, and its features and roles in-clude: transferring of AAA authentication messages, authoriza-tion and session accounting for subscriber sessions, and radio resource management [20]. The CSN provides IP connectiv-ity services to WiMAX subscribers meaning that the CSN cov-ers several functions such as: Internet access, AAA proxy and server, and Policy and Admission Control based on user’s sub-scription profiles[20]. The ASP is a business entity which pro-vides applications or services[20]. In this entity, the WiMAX Forum proposes two types of connection to an application: via a non-IMS application server and via P-CSCF (IMS). How-ever, it is not clear how to develop such a non-IMS Appli-cation Server [20]. Thus, we suppose that the WiMAX Fo-rum method uses the IMS-based Application Server to provide services for WiMAX subscribers. WiMAX has two types of inter-connectivities with other wireless networks such as LTE (3GPP): loose couple and tight couple[21]. Figure 2 shows how loose couple inter-working utilizes the AAA-server of a 3GPP network. Data streams are not passed through the core

Figure 2: Loose couple of inter-working between LTE/WiMAX and IMS.

Figure 3: Tight couple of inter-working between LTE/WiMAX and IMS.

network of a 3GPP LTE system. This method guarantees the independence of WiMAX network, however, it results in high handover latency between the two networks. The handover be-tween WLAN and UMTS was studied [22], and the average handover latency results for loose couple and tight couple were found to be 400ms and 150ms, respectively. Therefore, this op-tion is not suitable for real-time services. On the other hand, Figure 3 shows that a tight couple does apply to a RNC (Ra-dio Network Controller) and to the core network (SGSN and GGSN). The WiMAX’s BS connects to WCDMA’s RNC or SGSN directly. The advantage of this mode is that it reduces the handover latency and guarantees a seamless handover. In fact, it is possible to provide real-time services for WiMAX subscribers via IMS and the tight couple connectivity with LTE. Figure 2 and Fig.3 also show the proposed blocks of xBS (in WiMAX), XeNodeB (in LTE), and xAS, and their positions in-side the network. These blocks are essential in order to pro-vide our distributed scalable pro-video conferencing services on WiMAX/LTE networks.

3.2. Design requirements

The main target of this section is to provide the 4G mobile terminals the capability of using a distributed video conferenc-ing service based on the ALM-based overlay network to save

the cost of expensive MCU use as well as reducing the redun-dant signaling and data forwarding required by that overlay net-work. The solution is built based on IMS’s standards and 4G infrastructure. The main requirements of the design are to:

• Utilize available resource and information which can be easily obtained from the LTE/WiMAX infrastructure to ac-knowledge the ALM-based distributed conference so that the limited resources of the mobile terminals are used e ffi-ciently,

• Discard the standard centralized architecture that uses a MRFC thereby reducing the total expense of the entire so-lution and avoid the single point of failure while still main-taining multi-party conferencing features,

• Utilize floor control, a mechanism which coordinates si-multaneous access to shared resources in multimedia con-ferences. Floor control allows applications and users to gain safe and mutually exclusive or non-exclusive access to the shared resources. Floor control can be used to avoid or resolve conflicts among simultaneous media in-puts. For example, at any given time, the moderator of a floor can ensure that only one person is heard by other participants, or that one person types (writes) into a shared document. In our proposal, floor control is defined as the mechanisms with which to manage a conference ses-sion such as Join/Leave, Pause/Return, and Application layer Handover [23]. Floor control is required to pro-vide a well-managed conference service, floor control is required. Since floor control is not yet been considered for a distributed architecture, we need to find a solution to apply floor control mechanisms into our ALM-based con-ferencing architecture,

• Support a seamless integration among the LTE/WiMAX mobile terminals and the ALM-based conferencing plat-form during a mobile video conferencing session such as join/leave, pause/return, soft handover, heartbeat, etc.; and • Provide a QoS-guaranteed mechanism for QoS-required

ALM conferencing architecture systems.

3.3. Proposed protocol of the IMS-based LTE/WiMAX dis-tributed conferencing service

3.3.1. New features of our proposal

In this proposal, eNodeB(s)/xBS(s) are used as the proxy servers for bridging between the participating UEs and the dis-tributed conference. It will represent the UE in the overlay network as a representative overlay node. An AS (Application Server) will be used primarily to manage the floor control and the mapping between UEs and their proxy eNodeB/xBS. We call the extended version of eNodeB that supports the ALM’s protocol the XeNodeB, and the extended version of the AS the xAS. To obtain these design requirements (described in section 3.2), we propose new solutions to support a new version of eN-odeB/xBS:

Figure 4: LTE/WiMAX IMS-based distributed conference.

Figure 5: Representing nodes during Join/Leave.

• Application level soft handover: since our proposal is based on an overlay network in which the peers are ar-ranged in layers and clusters according to their connection conditions (bandwidth, delay, packet-loss, computational capacity, availability), it is mandatory to update this infor-mation whenever it is changed during the communication session. The xBS(s)/eNodeB(s) are used as proxies for wireless terminals to participate in the over-lay network, and so when the wireless terminals change their base sta-tions during the handover process at the wireless layer, the handover process must also be performed at the handover process at the overlay network (application level). This is required because each base station has its own capacity and available bandwidth and each wireless terminal has to update their resource reservation process before attaching to another base station. Since the new base station will represent the wireless terminal in the overlay network, the new connection conditions must be updated to the overlay network before the connection can be actually released in the radio layer to finish the handover process. If the old overlay node is deleted before the handover process fin-ishes, all forwarding traffic going through that node will be discarded. Therefore, for a smooth and effective soft han-dover process in the overlay network (application level), it is necessary to have a duplicated node in the overlay until the handover process at the radio layer is finished. The application layer handover can also reduce the unnec-essary cost to the mobile subscribers that occurs during pause/return,

Figure 6: Extended features of the XeNodeB.

• Heartbeat: A mechanism widely applied in over-lay/distributed architecture in which peers periodically send short messages to inform other peers about their ex-istence (whether the node is still alive and connecting) in the overlay. It also receives heartbeats from other peers updating about their existence. Many ALM algorithms have to depend on a heartbeat mechanism to maintain their group, and if the UE has to directly respond to all heart-beats, it will soon run out of power and computational ca-pacity. The heartbeat can be handled at the representative xBS/eNodeB level to prevent the UEs from being resource abused,

• Pause-Return: During the Pause-Return process of the UE(s) from the conference session, the representative eN-odeB/xBS can do the data forwarding work for the UE(s) in the overlay network. This new feature saves consider-able valuconsider-able radio resources on the part of the wireless mobile terminals,

• Join-Leave: While joining/leaving a conference, each UE has to pass through a QoS resource reservation process. The QoS parameters (bandwidth, delay, packet-loss) of the wireless connection is thereby confirmed for each UE. The representative eNodeB/xBS will create a node in the over-lay for each UE that it represents. The position of that newly created overlay node in the media distribution tree is determined by the application-aware cost function based on the confirmed QoS resource reservation of each UE. Hence, the representative eNodeB/xBS can create several nodes in the overlay network according to the number of UEs it is representing as shown in Fig.5. Our proposal will enable this process with the extended version of the xBS/eNodeB. The proposal has been briefly introduced in[19].

Many questions have been posed about whether the eN-odeB(s)/xBS(s) have enough computational capacity and intel-ligence to enable the functionalities required in a distributed ar-chitecture? The feasibility of using eNodeB/xBS for advanced features has been investigated in[24] and[25].

3.3.2. Detailed descriptions of XeNodedB and xAS

Figure 6 shows the extended features of the XeNodeB/xBS: • Participate as a node in the Overlays network;

Figure 7: Extended features of the xAS.

• Transfer or forward data and control messages; and • Scalable Video layer registration.

To achieve these features, each XeNodeB manages: • Routing tables:

– A listing UE participants served by that XeN-odeB. The list contains the UEs’ IP, Overlay role (source/relay/forwarding), status (idle/active), and registered video layer(s) (base/enhanced);

– Tables are updated based on the sta-tus(idle/left/active) of their managing UEs.

• A list of peers in the distributed conference containing the peer’s IP, distance (cost to reach that peer from the current XeNodeB).

• An Event Processor:

– Updates the participant list in join/leave, pause/return and handover operations, and

– Reports to xAS regarding the status (idle/left/active) of its managing UEs.

• An Overlay interface:

– The interface between its participating UEs and the overlay network,and

– Filters forwarding packets and send them back to the overlay network to save UEs capacity.

• A Signal processor:

– Obtains UEs status (availability, its available QoS level) from the xAS,

– Sends back UEs status to the distributed conference via the overlay interface as required.

• The QoS Video Layer registration: Checks each UEs available QoS and its registered video layers to see if they can be matched together.

Figure 7 shows the extended features of the xAS:

• Floor control for the video conferencing application: con-ference ID, participant’s list, participant’s status,

• Obtain UE-related information from the LTE/WiMAX network and forward to the overlaying nodes,

• QoS guarantee, conference’s QoS policies.

This xAS can be developed by operators and service providers and placed inside of a network. It then provides distributed video conferencing service for 4G users. xAS manages the vice and operators are usually included in providing such ser-vice. To achieve these features, each xAS manages a:

• Conference list: Contains conference ID, IP, XeNode ID, Conference status (in progress/terminated),

• Signaling processor:

– Receives requests from XeNodeB’s Signaling Pro-cessor; and

– Interrogates the UEs (QoS, availability...) from the Home Subscriber Server (HSS) and IMS and sends it back to XeNodeB’s Signaling Processor,

• Event processor:

– Receives updates from XeNodeB’s Event Processor about leave/join, pause/return, and handover; and – Updates the Conference list,

• Conference policy, including the:

– Starting time, duration, maximum number of partic-ipants,

– QoS requirements, and – Billing information.

Figure 8 shows the call flow when a UE wants to participate in or leave a distributed video conference. Firstly, when turned on, it automatically sends a REGISTER message to its XeN-odeB. The XeNodeB then updates its routing table and sends (eNodeB − ID, U E − S IP − Account) to the xAS. This infor-mation will be stored in the xAS’s Conference List. When the UE wants to initiates its participation in a distributed con-ference, it sends the INVITE(Conference ID, Layer Registra-tion) message, containing the maximum number of enhance-ment layer(s) it wants to receive from the conference mul-ticast tree, to the controlling XeNodeB. The XeNodeB con-verts the layer(s) number to a QoS parameter which is compre-hensible to the Policy Charging Rule Function (PCRF). Next, the INVITE message is forwarded to the xAS for mapping among the Conference-ID, UE-SIP-Account, and XeNodeB-ID in the xAS’s conference list. At the same time, the IN-VITE message is forwarded to the Policy Charging Enforce-ment Function (PCEF) using the Authorization-Authentication Request (AAR) message sent by the Call Session Control Func-tion (CSCF). The PCRF will check whether the UE has sub-scribed for enough QoS resource in order to receive the re-quired number of enhancement layers. If its subscription is sufficient, a resource reservation request will be sent to the PCEF to activate the resource policy for the UE to join the

/Return process over the distributed video conferencing service with QoS support.

Figure 11: Handling heartbeat operation in a distributed conference.

distributed conference[26]. The confirm resource is then re-ported to the xAS for updating of the QoS requirements and of the billing information in the Conference Policy[25]. Upon receiving the QoS confirmation, the XeNodeB sends an ALM’s JOIN-REQ(UE-SIP-Account, Layer-Reg) message to the ALM group to represent the UE participating in the ALM tree. Af-ter a new node has been successfully added to the ALM tree, a JOIN-REP(UE-ID, UE-SIP-Account, Lay-Reg) is sent to the XeNodeB. The UE-ID is assigned by the ALM and reported to the XeNodeB for management purposes. When the UE wants to leave the conference, a De-REGISTER(eNodeB-ID, UE-SIP-Account) is sent to the xAS and then a REQ-LEAVE(UE-ID) is sent to the ALM tree for a leaving request. The UE’s record is then removed from the xAS’s Conference List.

Figure 9 illustrates the Pause/Return operations of a UE over a distributed video conferencing service. During the conference session, the UE may want to suspend the service (it does not want to receive or transmit video streams and signaling mes-sages for a time duration) while preferring to be able to return to the ALM group with the smallest delay afterwards. Of course, if the suspending time is too long, the UE will be automatically discarded from the ALM group. When a UE wants to become idle, it sends the PAUSE(UE-SIP-Account) to the XeNodeB and to the xAS so that they can update their lists. The XeN-odeB then automatically sends a PAUSE-REQ(UE-ID) to the ALM group. The ALM group will stop sending bit-streams and signaling messages (HEARTBEAT) to the specific UE-ID, thus placing that UE on the waiting list of the ALM group within a certain time period. If the UE returns to the conference within that time period, it will only have to send a RETURN(UE-SIP-Account, UE-ID) to the RDV point of the ALM group and then comes back to the ALM tree. If the UE is idle beyond the set time period, it will automatically be discarded from the ALM

group’s waiting list. When working in the idle mode, the UE returns its reserved resources to the network via a Resource Modification process. The resource will be given back to the UE when it returns.

Figure 10 shows a UE going through a handover process while participating in a distributed conference. This process is com-patible with the 3GPP recommendation on the radio layer han-dover process in LTE/WiMAX[27]. The radio layer Han-dover process starts with the hard hanHan-dover of the mobile ter-minal in the radio level between two eNodeB/xBS[28]. It starts when the original eNodeB finds that the radio connec-tion with the UE is reducing to below a pre-defined level. The original eNodeB will contact the destination eNodeB with an HO Request. If everything is ok, the destination eN-odeB will acknowledge with a HO Response. The original eNodeB notifies the UE that it can start the handover pro-cess. At the service layer, when a UE is about to be handed over from the source to the destination XeNodeB, the destina-tion eNodeB sends an APPLICATION-LAYER-HANDOVER-SUBSCRIBE(Des-eNodeB-ID, UE Node id) to the xAS. The xAS will then update its list with this information and response the Destination eNodeB with an APPLICATION-LAYER-HANDOVER-SUBSCRIBE-ACK. Afterwards, the Destination eNodeB can create a duplicated node in the overlay by using REQ:MESSAGE-CREATE-DUP-NODE. The duplicated node will manage the data forwarding from the old node while the old node is performing its handover. A response is sent when the duplication is finished and confirmed. A new Resource Reser-vation process is made for the UE to be attached to the new eNodeB. At this time, two representing nodes are maintained by the two XeNodeBs in the ALM group in order to assure a soft handover process. Even though there are two nodes in the overlay, they are actually sending and receiving identical data.

The identical nodes send and receive bit-streams as any other normal node in the ALM group thus helping the UE to main-tain its conference service via both eNodeB/xBS until the old connection is actually broken. However, only the duplicated node has to manage the data forwarding required by the overlay network. After the handover is finished at the radio layer, the source XeNodeB sends a DELETE-DUP-NODE(UE id, Layer Registration, eNode ID) message to the ALM group and waits to receive the response to confirm that all is finished. It sends a confirmation message to the xAS so that it can be updated. In-formation regarding the old eNodeB will then be removed from the xAS. The old UE-ID is then removed from the ALM group and only one UE-ID will represent the UE in the conference. The handover process at the service layer is then finished and confirmed. Figure 11 shows the heartbeat handling process in the distributed conference with the support of the link measure-ment process available at the eNodeB. Heartbeat is the mech-anism widely applied in an overlay/distributed architecture, in which peers periodically send short messages to inform other peers about their existence in the overlay. It also receives heart-beats from other peers to update about their existence. Many ALM algorithms have to depend on a heartbeat mechanism to maintain their group. If a UE has to directly respond to all heartbeats it receives, it will soon run out of power and compu-tational capacity. Meanwhile, all information regarding a UE’s availability is available at the managing eNodeB, a simple link measurement interrogation operation triggered by the xAS can resolve this problem. Therefore, the XeNodeB will periodically consult the link status to query for the availability of all UEs that are joining the distributed conference under its representa-tive and report back to the xAS. The XeNodeB will then send back the heartbeats of all the UEs it is representing to the ALM group to signal their availability. For floor control purposes, the ALM-based distributed conference will update the list of peers participating in the conference to the xAS.

4. Prototype and performance evaluation 4.1. Evaluation method

A prototype designed to evaluate the proposal’s performance and its feasibility was developed and implemented. The pro-totype is publicly available at[29]. Figure 12 shows the proto-type’s architecture in which 4 UEs are participating in an ALM-based video conferencing service using a LTE/WiMAX infras-tructure with IMS support. We used OpenIMS[30] as the IMS core and the Mobicents platform to build the xAS and XeN-odeB. A distributed conferencing service was built based on[7]. A ”Rendez-vous” point in the overlay and the XeNodeBs are equipped with a SIP interface so that the overlay can commu-nicate with the xAS via the IMS core. We constructed 3 eval-uation scenarios run with different numbers of participants, in which four UEs participate via the IMS core:

• Scenario 1: Centralized IMS-based video conferencing us-ing MRFP, as recommended in the standards (i.e. LTE, WiMAX, IMS);

• Scenario 2: Conventional ALM-based distributed video conferencing service; and

• Scenario 3: Our proposed IMS-based distributed video conferencing service for LTE/WiMAX networks.

Scenario 1 is widely used as the standard architecture to provide the video conferencing services over wireless mobile networks. Scenario 2 can be referred to as the Web-NGN converged mul-timedia conferencing system. The most troublesome problem with this scenario (and which is investigated further in the eval-uation) is that, the mobile terminals are obligated to handle all the unnecessary signaling and data forwarding traffic that any other peer in the ALM group may handle (even though some peers may be work-stations on fixed networks with unlimited power, high computational capacity and high bandwidth con-nections). Therefore, the limited power of the mobile termi-nals will be rapidly used up and their poor radio resources filled up almost exclusively by the ALM’s unnecessary signaling and data forwarding traffic.

We selected these three scenarios because they help to explain how our proposal (scenario 3) can sharply reduce the redundant signaling and data forwarding traffic compared to the situation with the conventional overlay-based architecture (scenario 2). By comparing our solution, scenario 3, with the standard cen-tralized solution (scenario 1), we show that our proposed sce-nario has an equivalent traffic to the centralized architecture but with all the advantages (delay, flexibility, scalability, lower cost, single point of failure) of a distributed architecture as stated in section 2.

In all three scenarios, each peer sends 100 audio packets for au-dio conferencing and 300 video frames for video conferencing. The data was measured three times for each number of partic-ipants in each scenario for convergence purposes. In each of these scenarios, we built and applied:

• A prototype of our proposed distributed architecture with the sample nodes in the overlay network;

• A prototype of the proxy nodes running on BSs;

• A real audio conference open source software (sample au-dio packets obtained from real auau-dio conference sessions), • A prototype of a video conferencing service on the simple

overlay network and our proposed architecture; • A real SIP client; and

• An open source IMS platform (OpenIMS).

4.2. Evaluation results

The numerous advantages of the distributed architecture over the centralized architecture have been elaborated elsewhere, the main purpose of our research is not to compare our solution’s performance with that of centralized architecture and prove that our solution has a better performance. Once again, our purpose is to enable video conferencing service via distributed architec-ture for next generation wireless networks with only a slight

Figure 12: Architecture of the prototype.

Figure 13: Average number of signaling messages required during an audio conferencing session for each of the three scenarios.

Figure 14: Average number of signaling messages required during a video con-ferencing session for scenarios 2 and 3.

Figure 15: Average number of data packets sent/received at each participant during an audio conferencing session for scenarios 2 and 3.

Figure 16: Average number of data packets sent/received to/by each participant during a video conferencing session in scenario 2 and scenario 3.

modification of the 4G infrastructure and the IMS platform. To establish the distributed architecture over a mobile network, we have to resolve the crucial problem posed by requiring a high bit rate of wireless terminals. Therefore, we evaluate the per-formance of our proposal in terms of bit-rates for data and sig-naling plans.

Figure 13 and 14 show the average number of signaling mes-sages calculated at UE interfaces during an audio/video confer-encing session for all three scenarios (Fig.13) and for scenarios 2 and 3 (Fig.14). The result shows that scenario 2 needs to use much more signaling packets than scenario 3 to maintain a dis-tributed conference. Our solution, scenario 3 performs better because most of the signaling loads have been processed by the XeNodeBs.

Figure 15 and 16 show the comparison between the average data traffic monitored on UEs in scenarios 2 and 3 for an au-dio/video conference. Apparently, data traffic in scenario 3 is lower than in scenario 2 because the XeNodeBs have automat-ically routed the forwarding traffic for its managing UEs in the overlay. Therefore, the UEs only have to process the data traffic

Figure 17: Average number of data traffic sent/received to/by each partici-pant/MCU during an audio conferencing session of scenario 1 and scenario 3.

that is intentionally sent to them. We can hereby confirm that our scenario 3 has sharply reduced the traffic that mobile termi-nals have to contribute to maintain the overlay network. Figure 13 also shows that scenarios 1 and 3 require a similar number of signaling packets on UEs. We can conclude that our scenario 3 imposes a requirement similar to that of the standard-ized centralstandard-ized scenario, but with all benefits of the distributed architecture that are so obviously lacking in centralized archi-tecture.

Figure 17 shows that, the average data traffic at a UE in scenario 3 is slightly higher than the average UE traffic in scenario 1 but far less than the MCU’s average traffic in scenario 1. Appar-ently, the signaling and data traffic in scenario 1 is the smallest because it does not have to maintain a distributed architecture and the MCU is in charge of almost everything which comes with an excessively high cost. Our proposed scenario 3 has ful-filled our design requirements to reduce the data traffic at wire-less terminal while maintained all the benefits of a distributed architecture.

5. Conclusion

This paper proposes a new architecture for the inter-connectivity between UEs running on the LTE/WiMAX infrastructure and participating in an overlay-based distributed conference. Experimental results from the prototype have shown a great reduction in signaling traffic as well as in the data traffic handled by each UE and by the core network. The average bit rate required at the wireless terminals in our distributed architecture is equivalent to that of centralized architecture while it is much less than that required for conven-tional overlay networks.

Various conferencing scenarios such as join/leave, pause/return, application layer handover, and heartbeat have been considered in the prototype. The main contribution is that it enables an overlay-based video conference with all the benefits of a distributed architecture and without the disadvantages of too much traffic stressing the mobile terminals’ wireless connec-tions (an mandatory criterion for wireless networks). The

bit-rate required of wireless peers in our proposed distributed architecture is equivalent to that of a standard centralized case (based on results obtained from evaluating our prototype of audio and video distributed conferencing services). The results confirm that it is possible to apply distributed architectures in next generation of wireless networks. Taking advantage of 4G’s BSs means that the total cost of the conferencing services can be reduced and that these services can be provided with a minimum modification of relevant standards. The proposal replaces the standard centralized architecture of the IMS-based conference by a more robust solution utilizing intelligence and computational capacity of 4G’s BS(s). The prototype of our proposed distributed architecture for a multimedia service has shown that it can be integrated well into a 4G network. Its distributed nature leads to a considerable reduction in cost as well as more flexibility and scalability combined with smaller delay. The architecture can also be applied in WiMAX networks with a reasonable amount of modifications. The security for this distributed architecture can be inherited from the authentication and encryption mechanisms applied by LTE, WiMAX and SIP technologies.

Our solution profits from all the advantages of distributed architecture, such as flexibility, more scalability, smaller delay and lower cost. As a trade-off, some of the computational capacity of the infrastructure (core network and eNodeB/xBS) is required to enable distributed architecture in a mobile network. However, this situation is not really a disadvantage because the counterpart computational capacity required at the centralized media server (MRFC) is now distributed over the network infrastructure (eNodeB(s)/xBS(s) and the core network).

The only drawback of this solution is the computa-tional/intelligence requirements demanded of Base Stations. In 2G/3G, this solution might not be possible because the BSs were just simple antennas with very little capacity and intelligence and the Base Station Controllers (BSC) are sep-arated from BSs. In 4G, the BSC and the BSs are integrated into one entity the xBS (in WiMAX) or the eNodeB (in LTE). Therefore, the intelligence and capacity of the BSC is now available in xBS/eNodeB. They can now support a distributed architecture and make our proposal a realizable goal.

6. Acknowledgement

This research work is partly supported by POSEIDON, a French national project on the evaluation of the next genera-tion wireless network and its multimedia services. The authors are grateful to Quoc Tuan Tran, Quang Hoang Nguyen, and Hongguang Zhang for their prototype development and helpful discussions.

References

[1] L. De Cicco, S. Mascolo, V. Palmisano, Skype video responsiveness to bandwidth variations, in: Proceedings of the 18th International Workshop on Network and Operating Systems Support for Digital Audio and Video, ACM, 2008, pp. 81–86.

[2] S. A. Baset, H. Schulzrinne, An analysis of the skype peer-to-peer internet telephony protocol, Arxiv preprint cs/0412017.

[3] R. Spiers, N. Ventura, An Evaluation of Architectures for IMS Based Video Conferencing, University of Cape Town, Rondebosch South Africa.

[4] A. Garcia, Nefsis offers both free and for-pay versions, eWeek 27 (19) (2010) 40–41.

[5] I. Ekin Akkus, O. ”Ozkasap, M. Reha Civanlar, Peer-to-peer multipoint video conferencing with layered video, Journal of Network and Computer Applications.

[6] T. A. Le, H. Nguyen, Perception-based Application Layer Multicast Algorithm for scalable video conferencing, in: IEEE GLOBECOM 2011 -Communication Software, Services, and Multimedia Applications Sym-posium (GC’11 - CSWS), Houston, Texas, USA, 2011.

[7] T. A. Le, H. Nguyen, Centralized and distributed architectures of scalable video conferencing services, in: The Second International Conference on Ubiquitous and Future Networks (ICUFN 2010), Jeju Island, Korea, 2010, pp. 394–399.

[8] 3rd Generation Partnership Project, IP Multimedia Subsystem (IMS), Stage 2 (Release 5), 3GPP TS 23.228 5.

[9] 3gpp, Conferencing using the IP multimedia (IM)core network (CN) subsystem-ts 24.147, Tech. rep. (Mar. 2008).

[10] F. Belqasmi, C. Fu, M. Alrubaye, R. Glitho, Design and implementa-tion of advanced multimedia conferencing applicaimplementa-tions in the 3GPP IP multimedia subsystem, IEEE Communications Magazine 47 (11) (2009) 156–163.

[11] A. Buono, S. Loreto, L. Miniero, S. P. Romano, A distributed IMS en-abled conferencing architecture on top of a standard centralized confer-encing framework [IP Multimedia Systems (IMS) Infrastructure and Ser-vices], IEEE Communications Magazine 45 (3) (2007) 152–159. [12] S. E. Deering, D. R. Cheriton, Multicast routing in datagram

internet-works and extended LANs, ACM Transactions on Computer Systems (TOCS) 8 (2) (1990) 85–110.

[13] C. Diot, B. N. Levine, B. Lyles, H. Kassem, D. Balensiefen, Deployment issues for the IP multicast service and architecture, IEEE Network 14 (1) (2000) 78–88.

[14] C. Luo, W. Wang, J. Tang, J. Sun, J. Li, A Multiparty Videoconferencing System Over an Application-Level Multicast Protocol, IEEE Transactions on Multimedia 9 (8) (2007) 1621–1632.

[15] J. G. Andrews, A. Ghosh, R. Muhamed, Fundamentals of WIMAX, Pren-tice Hall USA, 2007.

[16] Q. T. Tran, T. A. Le, H. Nguyen, WiMAX-based overlay conferencing service, in: 2011 15th International Conference on Intelligence in Next Generation Networks (ICIN) - From Bits to Data, From Pipes to Clouds (ICIN 2011), Berlin, Germany, 2011.

[17] 3gpp, UTRA-UTRAN Long Term Evolution (LTE) and 3GPP System Architecture Evolution (SAE) (2005).

[18] P. Beming, L. Frid, G. Hall, P. Malm, T. Noren, M. Olsson, G. Rune, Lte-sae architecture and performance, Ericsson Review 3 (2007) 98–104. [19] T. A. Le, H. Nguyen, N. Crespi, IMS-based distributed multimedia con-ferencing service for LTE, in: 2012 IEEE Wireless Communications and Networking Conference: Services, Applications, and Business (IEEE WCNC 2012 Track 4 SAB), Paris, France, 2012.

[20] W. Forum, WiMAX Forum Network Architecture - Architecture, detailed Protocols and Procedures - Policy and Charging Control, Tech. rep. (Dec. 2009).

[21] F. Xu, L. Zhang, Z. Zhou, Interworking of Wimax and 3GPP networks based on IMS [IP Multimedia Systems (IMS) Infrastructure and Ser-vices], Communications Magazine, IEEE 45 (3) (2007) 144–150. [22] J. Song, S. Lee, D. Cho, Hybrid coupling scheme for UMTS and wireless

LAN interworking, in: Vehicular Technology Conference, 2003. VTC 2003-Fall. 2003 IEEE 58th, Vol. 4, IEEE, 2003, pp. 2247–2251. [23] X. Wu, Others, Use of session initiation protocol (SIP) and simple object

access protocol (SOAP) for conference floor control protocol (SOAP) for conference floor control, Tech. rep., Internet draft, Internet Engineering Task Force (2003).

[24] K. Daoud, P. Herbelin, N. Crespi, UFA: Ultra Flat Architecture for high bitrate services in mobile networks, in: IEEE 19th International Sym-posium on Personal, Indoor and Mobile Radio Communications, 2008. PIMRC 2008, 2008, pp. 1–6.

[25] K. Daoud, P. Herbelin, N. Crespi, One-Node-Based Mobile Architecture

for a Better QoS Control, IFIP Wireless days.

[26] W. Zhuang, Y. S. Gan, K. J. Loh, K. C. Chua, Policy-based QoS archi-tecture in the IP multimedia subsystem of UMTS, Network, IEEE 17 (3) (2003) 51–57.

[27] A. Racz, A. Temesvary, N. Reider, Handover Performance

in 3GPP Long Term Evolution (LTE) Systems, in: Mobile

and Wireless Communications Summit, 2007. 16th IST, 2007. doi:10.1109/ISTMWC.2007.4299068.

URL http://dx.doi.org/10.1109/ISTMWC.2007.4299068 [28] R. Y. Kim, I. Jung, X. Yang, C. C. Chou, Advanced handover schemes in

IMT-advanced systems [WiMAX/LTE Update], Communications Maga-zine, IEEE 48 (8) (2010) 78–85.

[29] T. A. Le, Q. T. Tran, Q. H. Nguyen, Multi-P2P prototype:

http://code.google.com/p/multi-p2p/ (2009). URL http://code.google.com/p/multi-p2p/

[30] F. Fokus, Open IMS Core, URL http://www. openimscore. org.

Table 1: Acronyms

3GPP 3rd Generation Partnership Project 4G 4th_{Generation Network}

AAA Authentication, Authorization, and Accounting AS Application Server

ASN Access Service Network ASP Access Service Provider BS Base Station

BSC Base Station Controller CSN Connectivity Service Network CSCF Call Session Control Function CAPEX Capital Expenditures

CDN Content Delivery Network eNodeB Evolved Node B

FCS Floor Control Server FCX Floor Control Mixer

GGSN Gateway GPRS Support Node GPRS General Packet Radio Service I-CSCF Interrogating CSCF

IMS IP Multimedia Subsystem MCU Multipoint Control Unit

MGCF Media Gateway Controller Function MGW Media Gateway

MRF Media Resource Function

MRFC Media Resource Function Controller MRFP Media Resource Function Processor MS Mobile Station

OPEX Operational Expenditure P2P Peer to Peer

P-CSCF Proxy CSCF

PCRF Policy and Charging Rule Function QoS Quality of Service

RNC Radio Network Controller RTP Real-time Transfer Protocol S-CSCF Serving CSCF

SN Super Node

SGSN Serving GPRS Support Node VC Video Conference