Available online at www.sciencedirect.com

Computer Networks 52 (2008) 228–247

www.elsevier.com/locate/comnet

Multicast/broadcast network convergence in nextgeneration mobile networks

Justino Santos a, Diogo Gomes a, Susana Sargento a, Rui L. Aguiar a,*,Nigel Baker b, Madiha Zafar b, Ahsan Ikram b

a Instituto de Telecomunicacoes, University of Aveiro, Aveiro, Portugalb Mobile and Ubiquitous Systems Group, CCCS Research, UWE, Bristol BS16 1QY, United Kingdom

Available online 8 September 2007

Abstract

The 3GPP Multimedia Broadcast Multicast Service (MBMS) aims to introduce group communications into the 3G net-works. One of the current key challenges is how to evolve these incipient features towards the ‘‘beyond 3G vision’’ of aconverged global network where multimedia content can be delivered over one or more selected broadcast transport bear-ers. This paper presents potential multicast/broadcast technologies convergence and discusses the issues and challenges inmoving towards this next generation network vision from the viewpoint of evolving MBMS.� 2007 Elsevier B.V. All rights reserved.

Keywords: IMS; MBMS; Multimedia and broadcast; Service enablers

1. Introduction

Multimedia applications and services range fromconventional TV broadcasting to personalized con-tent delivery, from traditional service-based multi-cast groups to context-aware gaming communities.Convergence of telephony, data, and video/TV ser-vices, in order to access media services over any typeof network, is often referred to as ‘‘triple play’’ infixed line telecommunications. Convergence of com-munications, media and broadcast industriestowards common technologies has opened up signif-icant business potential by offering entertainmentmedia and broadcast content to mobile users.

1389-1286/$ - see front matter � 2007 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2007.09.002

* Corresponding author.E-mail address: ruilaa@ua.pt (R.L. Aguiar).

A similar ‘‘mobile triple play’’ vision exists in themobile communications world. Here, an addedattraction is that broadcast/multicast techniquesoffer cost efficient delivery of content to large audi-ences in bandwidth-limited mobile radio access net-works. Wireless access networks, with thecontinuous technology evolution, will provide themeans of efficiently delivering data to severalusers–increasingly across several different accesstechnologies such as MBMS, DVB-H, WiMax orWiFi. Provisioning of multimedia streaming ser-vices (e.g., live TV) can easily be offered over severalaccess technologies in a ‘‘stove pipe’’ model. How-ever, enabling interactive and personalized stream-ing service delivery in an integrated model via anyaccess network requires a cooperative frameworkwithin the network infrastructure.

.

J. Santos et al. / Computer Networks 52 (2008) 228–247 229

The aim of the Next Generation Networks(NGNs) is to handle diverse types of services acrossdifferent types of access technologies. The main ten-ant of NGN architecture is that it allows decouplingof the network’s transport and service layers. Thismeans that, whenever a provider wants to enable anew service, it can do so by defining it directly atthe service layer without considering the transportlayer, thus making services independent of anytransport details. This is a business environmentbeing heavily pursued in the wired domain, limitedsolely by regulation restrictions.

The problem is: how can current mobile commu-nication infrastructures evolve to support thesetypes of communication and related services? Truenetwork convergence would envisage multicast–

Fig. 1. C-mobile vision – converged b

broadcast and group services delivered across sev-eral access networks with the added possibility ofseamless service mobility, as illustrated in Fig. 1.The solution for this problem is engaging many tele-communications standards groups, most notablyITU NGN Focus Group [1], Telecoms and Internetconverged Services and Protocols for AdvancedNetworks (TISPAN) [2], 3rd Generation Partner-ship Project (3GPP) [3], and the Open Mobile Alli-ance (OMA) [4]. These groups share some similar,but not coincidental, technological visions. Thisstudy departs from a Multimedia Broadcast Multi-cast Services (MBMS) [9] environment, and analy-ses how such a broadcast–multicast service mightevolve to meet this overall vision, and how it canbe related to (other) standards architectures.

roadcast–multicast architecture.

230 J. Santos et al. / Computer Networks 52 (2008) 228–247

This work is being pursued under theC-MOBILE project. The strategic objective of theC-MOBILE project [5] is to foster the evolution ofmulticast–broadcast services and, in particular, theevolution of MBMS towards this converged net-work vision. In the C-MOBILE project, a clearstrategy is defined for integration of MBMS intothe converged architecture utilizing a convergedcontrol plane based on IMS, as depicted in Fig. 1.An integrated IMS–MBMS architecture is definedto transparently support multicast and broadcastservices in NGN.

This paper starts from standard architectures forthe support of next generation networks, and clearlyidentifies the issues raised by the evolution path ofMBMS towards next generation networks, propos-ing (different stages of) evolved IMS–MBMSarchitectures for multicast/broadcast networkconvergence.

The paper is organized as follows. Section 2briefly presents standard architectures that aim atthe support of specific functionalities of NGN archi-tectures in a mobile environment, such as IMS,TISPAN, OMA and MBMS. Section 3 addressesthe IMS–MBMS architecture, its functionalities,and integration issues in a NGN architecture. Fol-lowing these integration issues, Section 4 proposesan evolved integrated approach for the interactionbetween MBMS and IMS, in order to build futuremobile multicast/broadcast services in an NGNenvironment, as discussed in Section 5. Finally, Sec-tion 6 presents final conclusions.

Fig. 2. IMS referenc

2. Standard architectures

In order to deliver services and media contentacross several access networks as depicted in Fig. 1,overall connectivity is required. Quality of service(QoS) and security must also be guaranteed acrossthese networks. A further level of transport provisionrequired comprises the functions to manage sessionestablishment and control communication such asvoice, multimedia and messaging. The complexityof realizing these tasks across technologies makesIP an essential supporting layer for these networks.

This section presents standard architectures thataim at the support of specific functionalities ofNGN architectures in a mobile environment. Theconcepts of these architectures and some ofthe architectures themselves will be the basis forthe proposed multicast/broadcast network conver-gence in the mobile telecommunications environ-ment. Given its commonality, IP layer issues willonly be mentioned where strictly essential.

2.1. IP Multimedia Sub-system (IMS)

One of the most promising NGN architectures isIP Multimedia Sub-system (IMS) [6]. IMS is astandardized NGN architecture for an Internetmedia-services capability defined by the EuropeanTelecommunications Standards Institute (ETSI)and 3GPP.

IMS has a layered architecture, which consists ofdelivery, control and service planes as illustrated in

e architecture.

J. Santos et al. / Computer Networks 52 (2008) 228–247 231

Fig. 2. It uses Session Initiation Protocol (SIP) forsession establishment, control, modification, andtermination of voice, video, and messaging betweentwo or more participants. These functions areimplemented in Call Session Control Functions(CSCFs), based on SIP proxies. Authentication,Authorization, and Accounting (AAA) within theIMS is based on the IETF Diameter protocol andis implemented in the Home Subscriber System(HSS), CSCFs, and various other IMS components.

The different CSCFs are known as Proxy CSCF(P-CSCF), Interrogating CSCF (I-CSCF) and Serv-ing CSCF (S-CSCF). The P-CSCF is the first accesspoint within the core network for the terminal start-ing session. It behaves like a proxy to accept requestsfrom the users and to either serve them internally orforward them. The P-CSCF is further responsiblefor authorizing bearer resources for the appropriateQoS level, identifying I-CSCF to forward therequests, enforcing local policies, and performingheader compression and decompression. The I-CSCF is then the contact point within an operator’snetwork for all connections to a subscriber of thatnetwork operator. It assigns an S-CSCF to each userperforming SIP registration, and may also act as aTopology Hiding Interworking Gateway. TheS-CSCF is the central node in the control signalingpath and is assigned to a user during registration.It is the anchor point for the interconnection withIMS applications servers (AS), allowing signalingto be routed between the users and ASs.

The HSS is the central repository for user relatedinformation. It stores IMS user and applicationserver profiles. The user profiles contain location,security, user status, and individual filtering infor-mation. This filter information is obtained and usedby the S-CSCF to route signaling requests fromusers to the desired AS. ASs enable the flexibledevelopment of multimedia applications includingconversational, streaming, and messaging type, orenhanced service enablers such as presence or groupmanagement; however, the IMS standards do notspecify how these applications should be developed.An AS communicates with S-CSCF and with HSSthrough a Diameter-based interface.

The Media Resource Function (MRF) can be splitup into the MRF Controller (MRFC) and the MRFProcessor (MRFP). It provides media stream pro-cessing resources for media mixing, media announce-ments, media analysis, and media transcoding.

Also important in IMS are the legacy concerns: theBorder Gateway Control Function (BGCF), Media

Gateway Control Function (MGCF), and MediaGateway (MG) are responsible for interworking thebearer between Real Time Transport Protocol(RTP)/IP networks and circuit switching networks.

A Policy Decision Function (PDF) is also definedwithin IMS, which authorizes media planeresources, e.g., QoS over the media plane. It is usedfor policy control and bandwidth management.

2.2. Telecoms and Internet Converged Services and

Protocols for Advanced Networks (TISPAN)

Although IMS is a major step forward towardsthe network convergence vision of delivering anymultimedia service over any network, it is still rudi-mentary in many aspects, such as coordinationrequired between access networks in networked dat-abases, admission and resource control.

TISPAN, also ETSI sponsored, is in charge ofaddressing these convergence issues, aiming at afixed-mobile convergence environment. As illus-trated in Fig. 3, TISPAN (Release 1) architectureis based on the concept of cooperating sub-systemssharing common components. This approach allowsthe addition of future sub-systems and ensures thatnetwork resources, applications, and user devicesare common to all sub-systems. The IMS Core,which is closely based upon 3GPP IMS Release 6,is one of these sub-systems. The Network Attach-ment Sub-system (NASS) and the Resource andAdmission Control Sub-System (RACS) are twoother relevant sub-systems, responsible for IP con-nectivity and QoS, respectively [8].

NASS provides address allocation, authentica-tion and authorization functions, access networkconfiguration and location management. RACSprovides QoS control (including resource reserva-tion, admission control and gate control), Networkand Port Address Translation (NAPT) and/or Fire-wall (FW) traversal control functionalities overaccess and core transport networks. Admission con-trol involves checking authorization based on userprofiles, Service Level Agreements (SLAs), operatorspecific policy rules, and resource availability withinaccess and core transport.

The inter-relation between all these sub-systemsis the key advance in the TISPAN architecture.

2.3. Open Mobile Alliance (OMA)

The sought-for convergence has also implicationsfor the top service layer of Fig. 1, as applications and

PSTN / ISDN Emulation

Application Layer

Network Attachment Subsystem

Resource and Admission Subsystem

UPSF

Streaming Subsystem RTSP-based

IMS core Subsystem

Access and Transport Layer

Other N

etworks

NG

N End Term

inals

Fig. 3. TISPAN reference architecture.

232 J. Santos et al. / Computer Networks 52 (2008) 228–247

services are many and diverse. Such applicationsmay be able to monitor or control multimedia ses-sions and may be accessed through a session controlprotocol such as SIP. Thus, these services are closelycoupled to the underlying network on which they arerunning, and therefore, a standard approach isrequired to deliver them across different networks.

The Open Mobile Alliance (OMA) is a standard-ization entity responsible for specifying market dri-ven service enablers that ensure serviceinteroperability across devices, geographies, serviceproviders, operators, and networks [4]. Examples

Presence Device Mg

OMA / 3rd

Digital Rights Management F

Applications

Policy Enforcers

Bindings

Enablers

Operator / Te

Fig. 4. OMA referen

of applications and services are presence, call con-ferencing, transcoding and billing. OMA specifiesan OMA Service Environment (OSE) [7], which isa flexible and extensible architecture that offers sup-port to a diverse group of application developersand service providers. OSE specifies enablers, whichprovide standardized components to create an envi-ronment in which services may be developed anddeployed. The OMA enablers, the decompositioninto these components, and the interactions betweenthem comprise the OSE. Fig. 4 illustrates the lay-ered architecture of the OSE and OMA enablers.

mt. BCAST Location

Party Applications

Billing ramework

Bindings

rminal / Service Provider Resources

ce architecture.

J. Santos et al. / Computer Networks 52 (2008) 228–247 233

There are a large number of enablers defined orpartially defined. Some have particular relevancefor our aims, such as BCAST, Presence, Transcod-ing, Group List Management and IMS Utilization.The later facilitates OMA services and applicationsto make use of IMS. It is clear from the previoussections that NGN convergence is multifaceted,requiring service convergence, session control con-vergence, architecture convergence and mobilityconvergence; OMA enablers provide solutions tothe service layer.

2.4. Multimedia Broadcast/Multicast Services

(MBMS)

Besides being instrumental to IMS development,3GPP also created the Multimedia Broadcast/Multicast Services (MBMS) [9], a sub-system stan-dardized since 3GPP release 6. MBMS allows deliv-ery of IP multicast datagrams to User Equipments(UEs) with specified QoS. On the control plane, itmanages bearer service activation status of theUEs, outsources authorization decisions to a newlyintroduced Broadcast Multicast Service Centre

Fig. 5. MBMS referen

(BM-SC), provides control of session initiation/termination by the MBMS user service, and man-ages bearer resources for the distribution of MBMSdata.

IP plays a key role in MBMS, being used to iden-tify the particular instance of the bearer service(which is composed of an IP multicast address andan access point name – network identifier) and tomanage all MBMS multicast services. The GatewayGPRS Support Node (GGSN) serves as the entrypoint for IP multicast traffic as MBMS data. Uponnotification from the BM-SC, the GGSN is respon-sible for setting up the required radio resources forthe MBMS transmission inside the UMTS Terres-trial Radio Access Network/GSM/EDGE RadioAccess Network (UTRAN/GERAN). The UTRANdecides on the appropriate radio bearer based onthe number of users within a cell, prior to, and dur-ing a MBMS transmission. Mobility aspects areintrinsically supported in UTRAN/GERAN, butfurther mobility needs to be supported by the Serv-ing GSN (SGSN), requiring the capability to store auser-specific MBMS context for each activated mul-ticast MBMS bearer service (Fig. 5).

ce architecture.

Service Announcement

Session Start

MBMS Notification

Data Transfer

Session Stop

Service Announcement

Session Start

MBMS Notification

Data Transfer

Session Stop

Subscription

Joining

Leaving

Broadcast Mode Multicast Mode

Fig. 6. MBMS broadcast and multicast phases.

234 J. Santos et al. / Computer Networks 52 (2008) 228–247

MBMS is able to operate in two modes: broad-cast and multicast (Fig. 6). The broadcast modeworks in a simplified manner, since it does notinvolve subscriptions management. It is composedup of five phases: service announcement, sessionstart, MBMS notification, data transfer and sessionstop. The service announcement is used to providethe UE with information on available MBMS ser-vices. The announced information includes parame-ters required for the service activation, such asservice start time and content information, securityparameters and associated delivery services. Thesession start phase is characterized by the triggerfor bearer resource establishment for MBMS trans-fer. In the next phase – MBMS notification phase –the UEs are informed of forthcoming and ongoingMBMS broadcast data transfers. The followingphase is the actual data transfer where UE receivesthe file or the announced streaming session. Finally,when the BM-SC has no more content to be deliv-ered, the session stop phase releases the bearerresources.

The MBMS multicast mode is more complexthan the broadcast mode. It considers higher levelmechanisms for subscription management in orderto optimize the distribution. For enabling such ser-vices, the multicast mode needs three more phases:subscription, joining and leaving. In the subscrip-tion phase, the UE must explicitly establish a rela-tionship with the service provider in order toreceive the MBMS multicast service via higher levelmechanisms, such as a Web portal or other definedservices. Then, the UE, for each subscribed service,receives service announcements in a similar way tothat of broadcast mode. Based on the receivedannouncements, the UE may initiate the joining

phase (typically through Multicast Listener Discov-ery (MLD) or Internet Group Management Proto-col (IGMP) messages). The following phases –session start, notification, data transfer and sessionstop – are again similar to the broadcast mode.The main difference is that a UE is able to performa leaving procedure, informing the BM-SC that itno longer wants to receive data from a specifiedservice.

3. IMS–MBMS converged architecture integration

issues

MBMS, via BM-SC, provides the means todeploy multicast/broadcast based on 3G technolo-gies as an independent system. It can work as astandalone technology since it has its own mecha-nisms of user accounting, charging, security, QoSand others. However, to be able to provide the sameservices in a heterogeneous environment, in a nextgeneration network, MBMS needs to be enhanced.The integration of the functionalities of bothMBMS and IMS could help on the developmentof a NGN architecture. The IMS–MBMS inte-grated architecture aims to support the followingfunctionalities:

• IMS-compatible signaling for efficient multicastsignaling, group management with context-awarecommunities and dynamic multicast groupaddress allocation.

• Scheduling and congestion control with adaptivesolutions based on feedback from the RadioAccess Network (RAN).

• Session management with RAN/bearer selectionin a converged environment.

J. Santos et al. / Computer Networks 52 (2008) 228–247 235

• QoS support for multicast/broadcast services(beyond unicast and multimedia ones).

• Transcoding strategies for provisioning of multi-layer services supporting use-cases such aslayered codecs and location-dependenttransmissions.

However, several issues on this integration needto be addressed to define such a converged IMS–MBMS architecture.

3.1. Architectural issues

As stated before, IMS is the chosen technologyfor session control and, to a certain extent, alsoinstrumental for architectural convergence. How-ever, IMS does not support delivery of multicast/broadcast services, which reduces its scalability. Ifthe MRF is enhanced to support multicast delivery,being able to either control a BM-SC or directlymulticast bearer services (MBMS or others), itwould be possible to improve the service providerresource usage.

A converged broadcast architecture based onIMS leads to the main approach of making IMSmulticast technology enabled. In other words itmust be possible to send multimedia content to agroup of IMS users through a multicast capabletechnology as a bearer, where MBMS is the mostprominent technology currently regarding multicastdelivery. One first architectural option is thus tohave a simple IMS and MBMS integration.

An IMS and MBMS integration first architec-tural option is to allow IMS applications to use

Fig. 7. IMS architecture u

MBMS, preserving as much of its functionalityand structure as possible. This is the approach inthe 3GPP study item [12]. The architecture of whichis shown in Fig. 7, where the BM-SC is presented asan entity inside IMS architecture to support MBMSbearers. This study group presents technical consid-erations and solutions for the facilitation of IMSservices over multicast bearer services with a focuson the possible enhancements to IMS functionalitiesand relevant charging, security and service provi-sion procedures. However, it considers the inclusionof BM-SC in the IMS architecture without clearlyspecifying how to solve the duplicate functionalityproblems and provide integrated interfaces.

In the situation where there are a number of pos-sible multicast–broadcast bearers, the IMS mustdecide somehow which multicast–broadcast bearerto use. The decision must be based on the particularapplication, UE capabilities, multicast/broadcastaccess network and QoS parameters. This requiresthat the basic broadcast/multicast support functionsare available at the service enabler layer and sessioncontrol layer. For MBMS, this would mean that thefunctionalities of the BM-SC would be distributedover IMS entities and service enablers.

3.2. MBMS functional evolvement and integration

The BM-SC provides mixed data path and con-trol management functionalities in one functionalentity. Several of the MBMS functions defined aregeneric to any multicast/broadcast services. Goodexamples of this are security, service discovery, ser-vice provisioning and user management. When con-

sing MBMS bearers.

236 J. Santos et al. / Computer Networks 52 (2008) 228–247

sidering NGN convergence, these functionalitiesneed to be abstracted in a way that they can bereused by several technologies. Fig. 8 presents theBM-SC functional structure within a UMTS net-work and covers the interfaces and protocols used.The centralized BM-SC comprises key MBMSsub-functions, described in the next paragraphs,along with integration and evolution issues raisedby the current status of the standards.

3.2.1. Membership function

The BM-SC membership function providesauthorization for UEs requesting activation of anMBMS service. This relates to Multicast join autho-rization, user membership management, time-related charging and subscription-related charging.This function manages bearer service membershipfunctions and the subscription related information(user profiles), authentication and authorization ofthe user. However, it is not completely clear in thecurrent release of the standards how and where userprofiles are stored or how services’ authorizationsare described.

In IMS, the HSS is the master user database: itcan further support the membership function role

S

U

A

GGSN

UE

Gi[http]

Gi [UDP/RTP, UDP/FLUTE]

Gi[http]

Gi[http]

Gi[UDP, MIKEY]

UE

UE

GGSN

Gmb

MembershipFunction

Proxy and TransportFunction

Gmb

Gmb

Gi [UDP/RTP, UDP/FLUTE]

UE

Fig. 8. BM-SC func

of BM-SC, holding authentication and authoriza-tion information to join a multicast group, userrelated information about services subscribed andothers. This would require a clear definition of thefunctionalities expected both from IMS andMBMS, and the respective interfaces.

3.2.2. Security function

The BM-SC security function is responsible forservice protection – limiting access to both broad-cast and especially to multicast transmissions to reg-istered subscribers. This is done by means of dataciphering and key distribution [10]. The MBMSKey Management function is used for distributingMBMS keys to authorized UEs. Before the UEcan receive MBMS keys, it needs to register at theKey Request sub-function. Once registered, theUE can request missing MBMS keys from theBM-SC by indicating the specific MBMS key ID,and deregister when desired. MBMS User Servicedata protection is optional, only needed if requestedby service announcement. The security dependsdirectly on the General Bootstrapping Architecture(GBA) [11] function for authorization and acquisi-tion of base key information.

ession & Transmission Function

Key ManagementFunction

Associated delivery Functions

MBMS DeliveryFunctions

Key RequestFunction

Key DistributionFunction

ser Service Discovery Function

Interactivennouncement Function

ContentProvider

Gi

tional entities.

J. Santos et al. / Computer Networks 52 (2008) 228–247 237

The scheme defined by MBMS is clearly depen-dent on 3GPP and only applies to MBMS technol-ogies. In our vision, the security scheme should befurther generalized in such a way that it could beused by different access technologies. Therefore,one possibility for security convergence is todevelop a specific enabler in IMS for key distribu-tion, and have the actual data traffic encryptiondone in the data delivery layer in the MRF function.

3.2.3. Proxy and transport function

The proxy and transport function acts as a gate-way between core network and the transport layer.It manages routing of data and reservation of bear-ers across the transport layer to the registeredGGSNs, while maintaining a clear separationbetween control layer (i.e., signaling) and trans-port/user plane (i.e., multicast payload). Also, itensures QoS parameters agreed upon during sessionestablishment by session and transmissionfunctions.

One main problem of the current MBMS archi-tecture is that it assumes that the BM-SC is com-pletely in charge of policy control and resourcereservation. However, it is advisable to considerintegration of the PDF functionalities that alreadyexist in IMS for media resource policy control withadaptations for the multicast/broadcast service’sresource authorization decisions. In [13] some ser-vice authorization issues are raised and hints abouta possible solution using a PDF entity are provided,but not deeply pursued.

3.2.4. Session and transmission functionThe session and transmission function is the

entity responsible for MBMS bearer session man-agement, authenticating and authorizing externalsources. It is also responsible for managing the con-tent repository and interacting with the contentprovider.

Its interface with Content Providers is notdefined in MBMS. It is unclear how content isauthorized to be distributed in the MBMS networkor how it is stored in case of non-real time services.In IMS, Application Servers (AS) define the way itdeploys hosts and executes services. This allows net-work operators or third party providers an easyintegration and deployment of their value addedservices, such as group management, enhancedannouncement services, or security support. Thus,it seems reasonable to have the interface with the

Content Provider either directly or indirectlythrough IMS AS.

Furthermore, in the current version of the stan-dards, the BM-SC is likely to be involved in sched-uling transmissions and resource reservation (andrelease) for MBMS transmissions. A BM-SC isresponsible for multicast broadcast service provi-sioning, so it might limit resource usage to someconfigured level, and reschedule file transmissionsfor a later time in case of high load in the network.It is also responsible for allocating resources tobearer services and providing the GGSN with trans-port associated parameters such as QoS and MBMSservice area, thus supporting location-specific trans-missions. As stated before, MBMS assumes thatBM-SC is in charge of policy control and couldclearly benefit with the integration of IMS PDFfunctionality for policy control. For streamingdelivery, the BM-SC may collect Quality of Experi-ence (QoE) reports. For download delivery, theBM-SC may collect reception acknowledgementsand statistical reception reports, although thesemechanisms are not clearly defined. IMS could per-fectly manage the reception of these reports througha specific application server responsible for sessionmanagement of multicast/broadcast services. Thisapplication server, after collecting this statisticalinformation, could then control the BM-SC, MRFor other specific entity to efficiently use the availableresources. The purpose of this approach is to notrestrict this mechanism to MBMS bearers.

3.3. Service discovery function

The BM-SC also provides service announcementsfor multicast and broadcast MBMS user services,including the media descriptions specifying themedia to be delivered as part of an MBMS user ser-vice (e.g., type of video and audio encodings). Inaddition, it also provides the UE with MBMS ses-sion descriptions specifying the MBMS sessions tobe delivered as part of an MBMS user service(e.g., multicast service identification, addressing,time of transmission, etc.). These media and sessiondescriptions are delivered by means of serviceannouncements using IETF specified protocols, likeSession Description Protocol (SDP) over MBMSmulticast and broadcast bearer services. It isreferred that an interactive announcement functionmay offer alternative means to provide servicedescriptions to the UE using HTTP or other interac-

238 J. Santos et al. / Computer Networks 52 (2008) 228–247

tive transport methods but they are not clearlydefined.

In MBMS no considerations are made concern-ing context or location awareness in serviceannouncement. It is possible to consider that newemerging service enablers being developed forIMS, such as group management, would be ade-quate tools for service announcement, bringinglocation and context-sensitivity into MBMS.

4. An evolved IMS–MBMS architecture

The challenge towards a long term evolution ofmulticast/broadcast services is to merge this tech-nology within a truly IP based NGN architecture.Current work within 3GPP Long Term Evolution(LTE) and System Architecture Evolution (SAE)initiative is on-going and is likely to develop further:it is expected to bring enhancements of packetswitched technology to cope with rapid growth inIP traffic through a fully IP network with simplifiedarchitecture and distributed control with heteroge-neous access. Similarly, the work on a next genera-tion IP-based converged network under TISPAN isalso in progress. In these cases, the whole concept ofgroup session inside MBMS needs to be rethought,as the transport layer may already support multicastcapabilities.

Taking the present status and trying to under-stand the basic premises of SAE, LTE and TISPAN,we developed and evaluated a possible architectureintegrating IMS with MBMS over an evolved net-work. In this architecture we propose to have theMBMS BM-SC functions completely distributed

Fig. 9. Evolved IMS–M

among the existing network entities (a centralizedBM-SC entity no longer exists). Also, the functionssuch as security, service announcement, and QoSprovisioning, are not kept specific to one accesstechnology; they are generalized to cope with anyaccess technology, and IP multicast is assumed ascommon transmission layer. In Fig. 9 we proposea new layered design, mainly based on IMS, butwe introduce more granularity to the picture: thedelivery plane is now divided into access and deliv-ery. Access relates to the access technology used bythe end user to achieve access to the network; deliv-ery concerns the converged IP layer. The serviceplane is also subdivided into application plane andservice enabler plane.

In the following sections, we explain in detaileach plane considered in the evolved architectureand the way the existing BM-SC functions are dis-tributed. Fig. 10 presents a detailed network entitydesign.

4.1. Access and transport plane

The access and transport plane is completely dis-tinct from the one in the MBMS standards: anevolved UMTS packet core is now considered,where the GTP tunneling mechanisms to supportmobility have been substituted by enhancedIP-based multicast and mobility mechanisms. Thistrend closely follows the SAE evolution as definedin [15] and a similar architecture has been definedin [14] with support for multicast mobility. One vis-ible consequence of this evolution is that the IPpacket network is now closer to the radio access

BMS architecture.

Access and Transport Plane

Go/S7

Cx/Dx

Content Providers

Plane

Streaming and

Download Source

Application Plane

IMS-based Control Plane

Ut

APIs

ISC/Ma

User Plane

Mb

Ut

Gm

Gmb

Gm

Media Delivery Plane

Ut

Ut

Media Delivery Function

Processor (MDFP)

Gi

Gq/Rx

Sh/Dh

Content Manager

Mb

Service EnablerPlane

Session Management

Enabler

MDFP or MRFP

Delivery Session Manager

Media P rocessor/Transcoder

Delivery Group Manager

Service Announcement

Enabler

Media Delivery Function Controller (MDFC) or MRFC

MDFP Location

Congestion Controller

Content Adaptation

M* - Session Man ager

Session Schedul ingController

MDFP Controller

M* -Transport

M*- UE BS Context

Managment

EvolvedPacket Core

HSSM* -Membership

M*- Session &Transmission

P/I/S-CSCF

M* - Proxy AndTransport

M* Distributed BMSC Functionality (M - Multicast)

Context-based Group Mgmt

Enabler

Gmb’Gi

PDF/PCRF

Content Mgmt Enabler

Service Scheduling

Enabler

Service Protection Enabler

Fig. 10. IMS and MBMS integration details.

J. Santos et al. / Computer Networks 52 (2008) 228–247 239

network, which allows IP convergence closer to theuser, reducing the access (technology specific) to asmaller area. Also, another important aspect is thatthis architecture is designed to cope with differenttypes of access networks. It is possible to considernot only a 3GPP evolved packet core, but also othertechnologies such as WiFi, WiMax or DVB-H (thelast one is very interesting in particular to multi-cast/broadcast services).

The evolved packet network architecture includesan access technology dependent element, the PCEF(Policy Control Enforcement Function), to controlthe (technology dependent) allocation of resources,the mapping of QoS parameters, and the enforce-ment of charging and policy. Generic interactionswith this entity are performed over the Gx interfaceas defined in [16] (however, [16] is still under heavydevelopment in 3GPP and still lacks the multicast/broadcast support). Our proposal for a multicast/broadcast enabled architecture redefines this Gx

interface in order to cope with enhanced supportto multicast bearer creation, allowing a user to join

a multicast group, set multicast related QoS param-eters, and provide generation and transmission ofcharging vectors for online or offline charging,among other functions.

4.2. Media Delivery Plane

Transport and pre-processing of content takesplace in this layer. Therefore several Media DeliveryFunction Processor (MDFP) entities are designed.MDFP extends the MRFP defined within IMS.The MDFP, in combination with Media DeliveryFunction Controller (MDFC), provides the cipher-ing of media (broadcast/multicast security), errorcorrection coding, mixing of different mediastreams, and transcoding. MDFP is placed as agateway between the Content Provider and theEvolved Packet Core. In addition, it also handlesthe enhanced group management and session man-agement delivery functions.

There are several candidates for the protocolused between MDFC and MDFP, such as SIP or

240 J. Santos et al. / Computer Networks 52 (2008) 228–247

H.246/MEGACO depending on the flexibility of therequired features. The interface between MRFCand MRFP also needs to be enhanced accordingto the implications over the control of multicastbearers.

4.3. Control Plane

The developed IMS-based control plane consistsof CSCF proxies, HSS, PCRF and MRF (consti-tuted by MDFC and MDFP). The Policy ControlResource Function (PCRF) is introduced in SAE/LTE as an extension of the IMS PDF componentfor harmonization of admission, charging andQoS mechanisms. It is mainly responsible for QoSaspects, policy management and charging functions.Through the Rx interface, it receives from the CSCFrequests from different Application Functions (suchas AS or UEs), using a Diameter based interface, foradmission and authorization of calls. This interfaceis defined in [17]. However, SAE/LTE vision ofPCRF is not yet multicast-capable and needs to beenhanced to cope with multicast/broadcast support.Our proposal is to enable the CSCF capability torequest policy decisions from the PCRF entity formulticast/broadcast services announced by applica-tion functions.

The PCRF entity also needs the support of anextended user database in order to obtain the userprofiles for policy decisions. The HSS needs smallenhancements to fulfill these functions. Joining ofservices is feasible with initial filter criteria placedin user profiles.

The S-CSCF contains service-triggered informa-tion in the form of initial filter criteria. When theuser equipment establishes a connection to ourarchitecture, the S-CSCF transfers the correspond-ing user profile from the HSS. The user profile con-tains the subscribed service groups. Whenever theconnection is set up, the S-CSCF executes servicetriggers and sends SIP messages to the group serverin the application layer. These SIP messages resultin service activation and thus allow service groupdelivery.

Scheduling and resource control is an aspect ofthe MDFC (the enhancement of the 3GPP MRFC).MRFC provides services for conferencing,announcements to a user or media transcoding inthe IMS architecture. To control the sources of con-tent, the MDFC has to support Content Providersto deliver specific content to a specific unicast, mul-ticast or broadcast address. MDFC functions

mainly are reservation and administration of multi-cast addresses – e.g., allocating unused multicastaddress for every multicast delivery session, findingan appropriate MDFP depending on users’ locationand multicast and multicast/broadcast servicescheduling.

4.4. Service Enabler Plane

In SAE/LTE specifications no detailed informa-tion is given about the Service Enabler and Applica-tion Layer. Most of the features and enablers alongwith interfaces will be evolved from IMS and OMAspecifications and architectures to function over anSAE/LTE network. In order to provide multicast/broadcast enabled services, we propose to definethe MB-SE (multicast/broadcast service enabler)as shown in Fig. 10 – some of these functions arealready found in an early stage in the R6 architec-ture BM-SC. These include:

• Security management functions including regis-tration for key updates, service key updates.

• Service description and service guide aggregationfor broadcast and multicast services.

• High level content scheduling.• Statistics collection for streaming and download

deliveries.• QoE statistics collection for streaming.• Group management (a separate service enabler is

defined and designed for group management).

The Content Management Enabler (CME) servesas an interface enabler between a service providerand a content provider. It provides control andpolicing of the type and amount of content allowedas part of a service and it allows the service providerto interface to the content provider.

The Context-based Group Management Enabler(CGME) not only handles the traditional multicast–broadcast group management, but also takes it astep further by incorporating context-awareness. Itis responsible for creation, deletion and manage-ment of user groups.

The Session Management Enabler (SME) is thecontact point for the end user. At the SME theusers register for the service they are interested inreceiving. All signalling flows between the MB-SEand the end user are handled by the SME. There-fore, it manages session start and session stop sig-naling. Bearer selection is another responsibility ofthe SME. The SME decides to use a multicast or

J. Santos et al. / Computer Networks 52 (2008) 228–247 241

broadcast bearer, depending on the registered userto a service, if the service provider has not defineda fixed bearer. And, based on the selection,appropriate address allocation is ensured by thisenabler.

The Service Scheduling Enabler (SSE) isresponsible for organizing the optimal schedule(order) of service/content deliveries in order toefficiently utilize the available resources in theCore Network (CN) and Radio Access Network(RAN). For this purpose it takes into accountthe spatial distribution of the users among thecells (to the extent possible) as well as the currentand the estimated RAN capacity (cell/area based).It further differentiates the various types ofservice (carousel, streaming, file download) andconsiders the defined QoS requirements (jitter,delay, bandwidth).

The Service Announcement Enabler (SAE) pro-vides service announcements describing the serviceto the end-user and is responsible for the distribu-tion of a service guide (ESG or EPG) to the end-users.

The Service Protection/Key Management entityis responsible for delivering service key updates(session keys or MSKs as in [10]) based on previ-ous UE registrations to receive these updates. Thisis done in R6 within the BM-SC based on HTTP.In the proposed architecture it is suggested to useSubscribe/Notify allowing the UEs to register toreceive key updates and acquire these updateswhen available from the BM-SC. Other BM-SCsecurity functions are distributed across the IMScore (authentication) and the MDFP (cipheringand traffic key generation).

4.5. Issues and Consequences for future convergence

The usage of this approach for future conver-gence presents some constrains and problems. Thekey point here is the increased integration and dis-tributed implementation of the MBMS architectureand concepts into the IMS sub-system.

From the point of view of 3GPP, this is actually achange in the existing deployment ideas: equipmentmanufacturers are now developing BM-SC and IMSboxes, mostly with low inter-relation. In fact, noteven the simpler integrated architecture presentedin Section 3 is now supported in any implementa-tion. The distributed BM-SC approach breaks thisdeployment structure, and impairs the evolution ofexisting/planned products.

The impact on TISPAN is not less, unfortu-nately. TISPAN advocates a clear sub-systemsapproach; here, IMS and MBMS seem to fit natu-rally. The distribution of the multicast/broadcastfunctionalities across the several entities breaks thisapproach, merging unicast and multicast services ina common platform.

On the other hand, the proposed approach ismore naturally adequate for a flexible environment,and especially to share the commonalities providedat the transport and control level. User personaliza-tion, media description, resource management andIP transport can be integrated, providing optimumservice provision regardless of the type of servicebeing provided.

4.6. Delivery issues

This section addresses some of the issues relevantfor an integrated NGN environment.

4.6.1. Scheduling/admission across RANs

Future NGN will have to cope with schedulingand admission problems across different RANs –and these problems will be more complex whenentertainment media is being handled. Admissionis always an issue associated with the user, throughthe HSSC and the PCRF, but network aspects aremore complex than this.

Considering traditional cellular environments,broadcast radio sub-carriers may (or may not) beallocated. This will depend on the interest/numberof users currently in the cell. The PCEF will haveto manage this process, including considering thedynamic change of carrier, depending on the totalcell available bandwidth for group communications,and on the total consumption at the moment. Thisconsiderably affects admission decisions, as algo-rithms will now need to consider these potentialchanges also.

The problem may be even more complex asbroadcast RANs are considered, such as DVB.Here, admission is immediate (a matter of allocatingthe user with the correct keys, at the multicast Ena-bler) but the scheduler needs to know that the UEhas the capability to receive information via suchinterfaces. Subscription is then not an immediateprocess (user subscribes to the interface that isactive), but a process where the interfaces able toreceive the specific content are explicitly mentioned.When discussing session mobility, this brings an

242 J. Santos et al. / Computer Networks 52 (2008) 228–247

added problem, in deciding which the best interfaceto continue a session is.

4.6.2. Resource usageThe previous paragraph clearly identifies issues

associated with resource management at the radioaccess. Changing streaming across technologies orchanging the type of logical channel at the radioaccess may bring added efficiency to the network.Naturally, the PCEF needs to handle this, but whenthe capability of switching technologies becomesimportant (e.g., all devices have WiFi, 3G andDVB interfaces), a new concept for PCEF isrequired: cross-technology optimization needs tobe in place.

A further aspect of the problem is related withthe wired-side optimization. Typically this is consid-ered the ‘‘core’’, but in most cellular systems, BaseStations (BS) are not directly in the core, but areconnected to this via a limited bandwidth line (oftenrented to a wired provider). This brings a clearincentive to distribute to each BS only the groupsthat are needed – and thus multicast tree optimiza-tions at the transport level are also important. Inour view, this is essentially handled at the IP level,and inherent to the whole process: the context man-agement guarantees that required groups are sub-scribed at a given BS.

4.6.3. Transcoding

The facilities of dynamically switching the deliveryof entertainment media can be optimally exploitedwhen content adaptation is present in the network.Delivery over a CDMA or WiFi channel, or a DVBstream, presents quite different technical problems,and is able to exploit quite different bandwidths.The content adaptation function in Fig. 10 can bedynamically invoked to provide to the UE the streamcoded with the best characteristics for the currentcarrier. The content provider will be oblivious of this,as transcoding can be dynamically provided as anadded value of a true NGN. The proxy and transportfunction distributed at access and delivery layers(Fig. 10) enables this feature for the converged archi-tecture. While sending data to the transport layer,delivery-proxy and transport function checks forthe carrier in use and transcodes accordingly.

4.6.4. Security

Security is needed at several levels in NGN:access control, confidentiality, and integrity,amongst others.

The network needs to avoid unauthorized access –which it inherently does: our proposal for integrationof multicast services in NGN handles access controlin a similar way as unicast services, with the user pro-file being stored in the same entities (HSS), but nowwith an added support from PCRF for QoS support.Nevertheless, broadcast services (in RANs such asDVB) need a paradigm extension to handle accesscontrol through key management. Note that theaccess to this key is made through the ‘‘bidirectional’’RANs, providing a simple and controllable mecha-nism to distribute these access keys.

On the same token, information confidentiality(e.g., adult services cannot be transmitted in openchannels in most countries) is also guaranteed bythe same method, for broadcast RANs. Whennon-broadcast logical channels are used (such as adedicated channel in 3G), confidentiality could beassured by the same mechanisms for unicast services(that is, through link-level security): however, thepotential session mobility that could occur at anyinstant as the user moves, argues in favor of alwaysretaining the same key-management based securitymechanisms for group services, regardless of aspectsof radio resource management.

5. Evolving multicast broadcast services

The convergence of the multicast–broadcast ser-vices and IP-based environments, as proposed forNGN, aims to open new business opportunities.Although many of these will depend on regulatoryaspects of merging broadcast and telecommunica-tion services, their significance for an open commu-nications market will eventually lead to theiremergence.

5.1. Multicast services

One of the areas where the integration of thesetwo areas may be simpler to support is associatedwith all aspects of closed-group services being deliv-ered in a heterogeneous network.

5.1.1. Evolved group services

Currently groups are handled inside telecomoperators mostly as a profile for certain customers,which have subscribed to different services. Ourapproach provides the flexibility for deployingmuch more complex intelligence in group serviceprovision. Access to groups now requires a specificrequest (as before), but which can eventually be

J. Santos et al. / Computer Networks 52 (2008) 228–247 243

transferred to AS, or to the content provider. Groupservices can now go through specific logic, and pro-vide different content to different users, dependingon many aspects: transcoding of informationaccording to the access network (as discussedabove); selection of the content according to theuser preferences (e.g., on transmitting a footballmatch, the transmission may push different camerasto the user according to its team preferences – thiscan be done easily by transmitting multiple flows,accessible by different keys) or subscriptions (a pre-mium user can have access to all the flows beingtransmitted from the game).

An advantage of our proposal is the fact that thespecific method to deploy these features could bepotentially different; however, for an optimumdeployment in terms of wireless resource manage-ment, different multicast trees should be createdinside the network, reaching only cells where thoseresources are needed.

5.1.2. Key service enablers

As discussed in the previous subsection, one ofthe main motivations to pursue IMS–MBMS inte-gration is to enable interactive, group-based andcontext-aware multicast services. Also, as discussedin Section 4, in our proposed architecture some ofthe BM-SC functionality is relocated at the serviceenabler layer in the converged architecture; we pres-ent this ported functionality as an enabler called

Multicast Broadcast - Se(MB — SE)

Content Provi

Device Management

Group Management

Enabler

Service Discovery Enabler

Session Manag

Converged IM

Other Enablers

MB-SE

SessioManagem

Enable

ServiceAnnounce

Enable

Context-based Group Mgmt

Enabler

Content Mgmt Enabler

Fig. 11. Broadcast/Multicast Service

Multicast Broadcast Service Enabler (MB-SE).Fig. 11 shows the structure of MB-SE and its inter-action with other enablers provided by the con-verged framework. As shown, multicast servicesinteract with other IMS–OMA enablers to carryout functions like scheduling, service discovery,charging and security.

It should be made clear at this point that multi-cast transmission is a scenario made possible by thisconverged architecture with added flavors of group-based and context-aware services. Therefore, for anend-to-end multicast transmission model, our MB-SE enabler makes use of other enablers specifiedin 3GPP and OMA specifications.

5.1.3. Context-aware Group Management

This optimality of tree creation for streaming dis-tribution creates an added dimension to group ser-vices, most especially to subscribed services relatedto information. Context (such as location) may leadto the creation of different groups: a video-servermay provide information about local points ofinterest, according to location (e.g., all restaurantsmay have a short promotional video distributed inthe ‘‘food information service’’, and depending onthe location, users will be allocated to different mul-ticast groups, and thus receive different streams).This can be also different depending on other con-text aspects, such as: e.g., current weather (receivingvideo promotion about a nice cafe in the middle of

rvice Enabler

Security Enabler

PresenceEnabler

der

ement Enabler

S-MBMS Core

Charging Enabler

n ent r

ment r

Service Scheduling

Enabler

Service Protection Enabler

Enabler – functional structure.

1 OpenIMs is a public availaiable IMS stack. See http://www.fokus.fraunhofer.de/ims/index.php.

2 GStreamer is an Open Source Media Stack. See http://gstreamer.freedesktop.org/.

3 VideoLan is a highly portable multimedia player. See http://www.videolan.org/vlc/.

4 MAD-FLUTE is a multicast file transfer tool based onFLUTE protocol. See http://atm.tut.fi/mad/.

5 Sofia-SIP is an Open Source User-Agent library. See http://opensource.nokia.com/projects/sofia-sip/.

6 NIST-SIP is an Open Source User-Agent. See http://snad.ncsl.nist.gov/proj/iptel/.

7 Nokia N800 is an Internet Tablet device. See http://www.nseries.com/products/n800/.

244 J. Santos et al. / Computer Networks 52 (2008) 228–247

the park is probably not very effective during athunderstorm).

On the other hand, users may also push theircontent locally – the development of environmentslike youtube is a good indication of this interest.Communities – in the sense of groups of interrelatedusers – can be dynamically supported, as long as agroup management service is in place. This service,providing simply key management and a traffic ren-dezvous point, may allow closed groups to be cre-ated, and user-originated content to be distributedinside that group.

5.2. Broadcast Services

Broadcast services, in its most basic function,means the same content to all users, regardless ofthe user. Nevertheless, broadcast services also bene-fit from synergies inside NGN.

5.2.1. Evolved Broadcast services

If the content of broadcast services aims to be thesame to all interested users, there are two aspectsthat benefit from an individual separation: (i) adver-tising; (ii) content authorization.

On the first point, the integration of broadcastservices inside NGN allows for a much more effec-tive exploitation of advertising. Today, marketingalready positions its publicity in different channels,at different times, according to the presumed userstratification. It seems obvious in our structure toallow advertising time to be fine-tuned to users,depending on location, context, or even their prefer-ences. Broadcasters would then resort to multicastgroups during advertising time.

The second point is associated with contentauthorization. Broadcasters are having increasedlimitations on content distribution according toissues such as violence, profanity or adult content.With an integrated environment, all these contenttypes could be transmitted without restrictions:viewing is individual – mobile devices are not forcommon viewing, and as such the user may chooseto see whatever content he wants, as if the transmis-sion were made in a paid-channel. Age restrictionscan be placed at the subscription time, with usersbeing allowed (or not) to access restricted contentbased on their age.

5.2.2. Key service enablers

In terms of functional components and enablersrequired, broadcast can be seen as a subset of mul-

ticast transmission. Referring back to Fig. 11, forbroadcast transmission, key service enablers wouldbe the same, apart from key management, key dis-tribution and membership functions which are notrequired for a broadcast transmission setup.

6. Prototype implementation

In order to evaluate the benefits of the proposedarchitecture, a testbed was implemented in thescope of C-MOBILE project. The testbed elementscan be subdivided into 3 classes: Emulators, OpenSource Components and Custom DevelopedSoftware.

The Emulators class is required by RAN testingissues: a RAN emulator is used, which enables thetesting of the architecture over a common 802.11wireless network without the need of expensive 3Gradio equipment.

The Open Source Components chosen for thetestbed comprise OpenIMS,1 GStreamer,2 Video-Lan,3 MAD Flute,4 Sofia SIP5 C/C++ stack, andNIST-SIP6 JAVA stack. The platforms use NokiaN8007 Linux and desktop computers running Linux(Ubuntu 7.04) and FreeBSD, providing with thebasic building blocks to construct the network andplatform.

Additionally, several components were needed tobe developed from scratch such as the User Equip-ment Interface, and the Application Server with allits Service Enablers. Some other components werealso significantly modified from existing privatesoftware, as was the case of the Media DeliveryFunction and Content Provider.

The deployment view of the test bed componentsand their implementation and functions is describedas depicted in Fig. 12.

Fig. 12. Demonstrator components.

J. Santos et al. / Computer Networks 52 (2008) 228–247 245

6.1. Components

The RAN emulator takes as input the outcomeof C-MOBILE simulations and reflects these resultsin terms of L3 behavior, as configurable parametersto a transparent shaping software placed in betweenthe 802.11 Access Point and the last IP Multicastrouter (see Fig. 12). This emulator allows the settingof IP QoS parameters (through-put, delay, loss) ona per flow basis providing a good reference to whatthe real behavior of traffic would be, under differentradio channel conditions.

In the core network the OpenIMS is used sinceit provides a relatively stable and compliant IMSplatform capable of being extended. On top of thisIMS platform a simplified Application Server (AS)was developed. The AS is basically composed bythe Session Management Enabler (SME); the Con-text based Group Management Enable (CGME);and Session Scheduler Enabler (SSE). The simpli-fied AS makes available a protocol abstractionAPI so that service enablers such as the SME cansend SIP messages without actually knowing SIP

– resembling as much as possible a ResourceAdapter.

The Media Delivery Function (MDF) is imple-mented by wrapping MAD Flute and VideoLandelivery engines for download and streaming, withcontrol logic and communication abilities on topof them.

The Content Provider is the least complex of theprototyped entities and consists of a simple filerepository that can be accessed by the MDF andService Enablers through HTTP.

Finally, the User Equipment is Nokia’s N800Internet tablet device, which albeit slightly largerthan 1st generation UMTS User Equipments, pro-vides easy to program connectivity and multimediafeatures (such as 802.11 interface and hardware basecodec support through the Open Source MediaFramework GStreamer).

The testbed is able to support both IPv4 andIPv6 Multicast through the SIP Stacks used andOpenIMS dual stack support and the availabilityof Multicast Routing Daemons for Linux andFreeBSD.

246 J. Santos et al. / Computer Networks 52 (2008) 228–247

6.2. Testbed Scenarios and Results

The testcase scenarios evaluated consist of Inter-active TV and Content Casting.

The Interactive TV scenario is a very commonscenario and is intended to demonstrate that thearchitecture not only fully supports current businesscases, but also provides added value such as contextbased interactivity (e.g., location specific program-ming). The Content Casting scenario context isagain explored (e.g., based on user presence)together with Scheduling of Services (e.g., files aretransmitted only when network usage is low) andSessions can be dynamically shifted from betweenMulticast and Unicast through the Session Manage-ment Enabler in order to optimize networkresources.

One should notice that the great advantage ofthis architecture lies in the service enabler capabil-ities. Network-wise, the performance of the dem-onstrator is not different from usual IP networks:we have results in the range of 70–80 ms for basic(no Service Enablers involved) Multicast IMS Ses-sion Setup. However, the processing logic on theservice enablers is the dominant aspect here. It isnot surprising that this logic takes a couple of sec-onds depending on the use case, but this is notreally relevant from the user point of view, sincethis is the initial service request time. Afterwards,the user notices the service actual delivery, whichin the tests achieved good user experience for bothscenarios.

Prototype evaluation of Service Enablers is verydifficult to be performed in terms of metrics, as itis very dependent on the current Context of the Net-work. User experience and the ability to experiencenew services, therefore, become the main vehicles toclassify the success of our architecture in realenvironments.

7. Future work and conclusion

This paper presents an architecture which inte-grates group communications in a NGN environ-ment. This architecture is shown in anevolutionary way, with a first instantiation simplybringing the IMS and the MBMS sub-systemstogether. In a second more evolved approach,resorting to an All-IP concept, our architecture isdeveloped in terms of deployment, leading to a dis-tribution of all group-functionalities by differententities.

This integrated approach exposes newapproaches to group and broadcast services, wherethe resource usage efficiency of broadcast/multicasttechniques can be merged with individualized inter-ests, creating new and more efficient paradigmsboth for network and content providers. The pro-totype was functionally evaluated, and this pro-vides insights for commercial deployment of thissolution.

Acknowledgements

This work was performed as part of EU-IST pro-ject C-MOBILE (Advanced MBMS for the FutureMobile World) (http://c-mobile.ptinovacao.pt/home.html) (IST-2005-27423). We are thankful toall the partners for their contributions.

References

[1] ITU Focus Group on Next Generation Networks(FGNGN). <http://www.itu.int/ITU-T/ngn/fgngn/>.

[2] Telecoms & Internet converged Services & Protocols forAdvanced Networks. <http://www.etsi.org/tispan/>.

[3] 3rd Generation Partnership Project. <http://www.3gpp.org>.[4] Open Mobile Alliance. <http://www.openmobilealliance.

org>.[5] C-MOBILE project web page: <http://c-mobile.

ptinovacao.pt>.[6] 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2.[7] OMA WID_0075 OMA Service Provider Environment

(OSPE) for Improving Integration, Deployment andManagement.

[8] R. Brennan et al., TISPAN NGN Architecture Overview,TISPAN-3GPP Workshop, Washington, 30–31 March 2005.

[9] 3GPP TS 23.246, Multimedia Broadcast/Multicast Service(MBMS); Architecture and functional description.

[10] 3GPP TS 33.246, 3G Security; Security of MultimediaBroadcast/Multicast Service (MBMS).

[11] 3GPP TS 33.220, Generic Authentication Architecture(GAA); Generic Bootstrapping Architecture.

[12] 3GPP TR 23.847, Enhancements to IMS service functional-ities facilitating multicast bearer services.

[13] J. Ogunbekun, A. Mendjeli, MBMS service provision and itschallenges, 3G Mobile Communication Technologies, 2003.3G 2003, in: 4th International Conference on (Conf. Publ.No. 494), 25–27 June 2003, pp. 128–133.

[14] G. Leoleis, L. Dimopoulou, V. Nikas, I.S. Venieris, Mobilitymanagement for multicast sessions in a UMTS-IP convergedenvironment, Computers and Communications, 2004, in:Proceedings ISCC 2004. Ninth International Symposium on,vol. 1, 28 June 1–July 2004, pp. 506–511.

[15] 3GPP TR 23.882, System architecture evolution (SAE):Report on technical options and conclusions.

[16] 3GPP TS 29.212, Policy and charging control over Gxreference point.

[17] 3GPP TS 29.214, Policy and charging control over Rxreference point.

r Networks 52 (2008) 228–247 247

Justino Santos received his degree in

Computers and Telematics Engineeringfrom the University of Aveiro on 2005.The graduation also included a sixmonth internship at NEC Europe Labs,Germany where he worked in VehiclularAd-hoc Networks and Location Privacy.In September 2005, he joined the Insti-tute of Telecommunications of the Uni-versity of Aveiro, where he was aresearcher. His main topics of interest

are multicast/broadcast technologies in next generation hetero-geneous networks.

J. Santos et al. / Compute

Diogo Gomes graduated in Computersand Telematics Engineering from theUniversity of Aveiro in 2003 with firstclass honors, and has since been workingtowards a PhD degree in hhQoS signalingin broadcast enabled technologiesii atthe same university. Since his graduationyear, he has participated in several ISTProjects such as IST-Mobydick, IST-Daidalos and IST-Akogrimo where hehandled QoS and mobility related issues

as well as prototype implementations. Recently he participates inIST-C-MOBILE where he holds leadership responsibilities on the

deployment of a demonstrator for the project. His researchinterests include Multicast, Mobility and QoS.

Susana Sargento graduated in Electron-ics and Telecommunications Engineeringfrom the University of Aveiro in 1997,and concluded her PhD in 2003. InSeptember 2002, she joined the Depart-ment of Computer Science of the Facultyof Sciences of the University of Porto,where she also led the Computer Net-works Group at LIACC-UP. Shereturned to the University of Aveiro andthe Institute of Telecommunications in

February 2004. Her main research interests are in the areas ofnext generation and heterogeneous networks, infrastructure,

mesh and ad-hoc networks.

Rui L. Aguiar received a Ph.D. degree inelectrical engineering in 2001 from theUniversity of Aveiro, Portugal. He iscurrently an assistant professor at theUniversity of Aveiro and is also leading ateam at the Institute of Telecommuni-cations, Aveiro, on next-generation net-work architectures and protocols. Hiscurrent research interests are centered onthe implementation of advanced wirelessnetworks, systems, and circuits, with

special emphasis on QoS and mobility aspects, areas where he has

more than 150 published papers. He is currently TPC-CoChair ofISCC’07.

Nigel Baker is Head of the Mobile andUbiquitous Systems Group, Co-Directorof CCCS Research, Associate Professor(Reader) in Computer Science and until2006 Motorola Fellow. His first degreeswere in Physics and Nuclear and ParticlePhysics. His specialties in the last twentyyears have been Real Time Systems,Computer Networks, Distributed Sys-tems and in the last decade MobileCommunications. He has written

numerous Journal and conference papers and been a member ofmany conference and workshop committees covering these topics

over the years. He was a visiting researcher at CERN Geneva forsix years and worked on several projects; the two most notablewere CICERO and CRISTAL. He developed and led the MobileApplications of Software Technologies (MAST) Programme.

Madiha Zafar is a researcher at UWE,Bristol with the Mobile and UbiquitousSystems Group. She graduated fromNational University of Sciences andTechnology (NUST), Pakistan in 2004with distinction. From 2005 to mid 2006she was a Research Associate at Moto-rola Ltd., Swindon, where she wasinvolved in research related to mobilemulticast and broadcast technologiesand participated in the development,

testing and demonstration of MBMS-enabled UMTS simulatorfor EU IST FP6 project B-BONE. Currently she is part of the EU

IST FP6 project C-MOBILE. Her research interests lies in thedomain of ubiquitous systems, smart spaces and context-awarecommunication.

Ahsan Ikram is a post graduate studentand researcher with Mobile and Ubiq-uitous Systems Group at University ofthe West of England (UWE), Bristol,UK. He received his BS (SoftwareEngineering) in 2004 from NationalUniversity of Sciences and Technology(NUST), Pakistan. Before joining UWEhe has worked at NUST, Pakistan andthe California Institute of Technology(Caltech), USA, as a Research Associate.

His main areas of research have been distributed computing,mobile computing and mobile application development. His

research interests are next generation mobile networks, applica-tions and sensor networks. Currently, he is working on EU ISTFP6 project C-MOBILE.