Multicast/Broadcast Network Convergence in Next ... - CiteSeerX

Multicast/Broadcast Network Convergence in Next Generation Mobile Networks Justino Santos*, Susana Sargento*, Rui L. Aguiar*, Nigel Baker**, Madiha Zafar**, Ahsan Ikram** * Instituto de Telecomunicações, University of Aveiro, Aveiro, Portugal **Mobile & Ubiquitous Systems Group, CCCS Research, UWE, Bristol, UK BS16 1QY

Abstract The 3GPP Multimedia Broadcast Multicast Service (MBMS) aims to introduce group communications into the 3G networks. One of the current key challenges is how to evolve these incipient features towards the “beyond 3G vision” of a converged global network where multimedia content can be delivered over one or more selected broadcast transport bearers. This paper presents potential multicast/broadcast technologies convergence and discusses the issues and challenges in moving towards this next generation network vision from the viewpoint of evolving MBMS.

1.

Introduction

Multimedia applications and services range from conventional TV broadcasting to personalized content delivery, from traditional service-based multicast groups to context-aware gaming communities. Convergence of telephony, data and video/TV services, in order to access media services over any type of network, is often referred to as “triple play” in fixed line telecommunications. Convergence of communications, media and broadcast industries towards common technologies has opened up significant business potential by offering entertainment media and broadcast content to mobile users. A similar “mobile triple play” vision exists in the mobile communications world. Here, an added attraction is that broadcast/multicast techniques offer cost efficient delivery of content to large audiences in the bandwidth limited mobile radio access networks. Wireless access networks, with the continuous technology evolution, will provide the means of delivering efficiently data to several users - increasingly across several different access technologies such as MBMS, DVB-H, WiMax or WiFi. Provisioning of multimedia streaming services (e.g. live TV) can easily be offered over several access technologies in a “stove pipe” model. However, enabling interactive and personalized streaming services in an integrated model to deliver across any access network requires a cooperative framework within the network infrastructure. The aim of the Next Generation Networks (NGN) is to handle diverse types of services across different types of access technologies. The main tenant of NGN architecture is that it allows decoupling of the network's transport and service layers. This means that, whenever a provider wants to enable a new service, it can do so by defining it directly at the service layer without considering the transport layer, thus making services independent of any transport details. This is a business environment being heavily pursued in the wired environment, limited solely by regulation restrictions.

The problem is: how can current mobile communication infrastructures evolve to support these types of communication and related services? True network convergence would envisage multicast-broadcast and group services delivered across several access networks with the added possibility of seamless service mobility, as illustrated in Figure 1. The answer to this problem is engaging many telecommunications standards groups, most notably ITU NGN Focus Group [1], Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) [2], 3rd Generation Partnership Project (3GPP) [3], and the OMA (Open Mobile Alliance) [4]. These groups share some similar, but not coincidental, technological visions. This study departs from a Multimedia Broadcast Multicast Services (MBMS) [9] environment, and analyses how such a broadcast-multicast service might evolve to meet this overall vision, and how it can be related to (other) standards architectures.

Figure 1: C-Mobile Vision - Converged Broadcast-Multicast Architecture

This work is being pursued inside the C-MOBILE project. The strategic objective of C-MOBILE project [5] is to foster the evolution of multicast-broadcast services and, in particular, the evolution of MBMS towards this converged network vision. In CMOBILE project, a clear strategy is defined for integration of MBMS into the converged architecture utilizing a converged control plane based on IMS, as depicted in Figure 1. An integrated IMS-MBMS architecture is defined to transparently support multicast and broadcast services in NGN. This paper starts from standard architectures for the support of next generation networks, and clearly identifies the issues raised by the evolution path of MBMS towards next generation networks, proposing (different stages of) evolved IMS – MBMS architectures for Multicast/Broadcast network convergence. The paper is organized as follows. Section 2 briefly presents standard architectures that aim at the support of specific functionalities of NGN architectures in a mobile environment, such as IMS, TISPAN, OMA and MBMS. Section 3 addresses the IMSMBMS architecture, its functionalities, and integration issues in a NGN architecture. Following these integration issues, section 4 proposes an evolved integrated approach for the interaction between MBMS and IMS, in order to build future mobile multicast/broadcast services in an NGN environment, illustrated in section 5. Finally, section 6 presents final conclusions.

2.

Standard Architectures

In order to deliver services and media content across several access networks as depicted in Figure 1, overall connectivity required. Quality of service (QoS) and security must also be guaranteed across these networks. A further level of transport provision required comprises the functions to manage session establishment and control communication such as voice, multimedia and messaging. The complexity of realizing these tasks across technologies makes IP an essential supporting layer for these networks. This section presents standard architectures that aim at the support of specific functionalities of NGN architectures in a mobile environment. The concepts of these architectures and some of the architectures themselves will be the basis for the proposed multicast/broadcast network convergence in the mobile telecommunications environment. Given its commonality, IP layer issues will only be mentioned where strictly essential.

2.1. IP Multimedia Sub system (IMS) One of the most promising NGN architectures is IP Multimedia Subsystem (IMS) [6]. IMS is a standardized NGN architecture for an Internet media-services capability defined by the European Telecommunications Standards Institute (ETSI) and 3GPP. IMS has a layered architecture, which consists of delivery, control and service planes as illustrated in Figure 2. It uses Session Initiation Protocol (SIP) for session establishment, control, modification, and termination of voice, video, and messaging between two or more participants. These functions are implemented in Call Session Control Functions (CSCFs), based on SIP proxies. Authentication, Authorization, and Accounting (AAA) within the IMS is based on the IETF Diameter protocol and is implemented in the Home Subscriber System (HSS), CSCFs, and various other IMS components. The different CSCF are known as Proxy CSCF (P-CSCF), Interrogating CSCF (ICSCF) and Serving CSCF (S-CSCF). The P-CSCF is the first access point within the core network for the terminal starting session. It behaves like a proxy to accept requests from the users and to either serve them internally or forward them. The PCSCF is further responsible for authorizing bearer resources for the appropriate QoS level, identifying I-CSCF to forward the requests, enforce local policies, and perform header compression and decompression. The I-CSCF is then the contact point within an operator's network for all connections to a subscriber of that network operator. It assigns an S-CSCF to each user performing SIP registration, and may also act as a Topology Hiding Interworking Gateway. The S-CSCF is the central node in the control signaling path and is assigned to a user during registration. It is the anchor point for the interconnection with IMS applications servers (AS), allowing signaling to be routed between the users and ASs. The HSS is the central repository for user related information. It stores IMS user and application server profiles. The user profiles contain location, security, user status, and individual filtering information. This filter information is obtained and used by the S-CSCF to route signaling requests from users to the desired AS. ASs enable the flexible development of multimedia applications including conversational, streaming, and messaging type, or enhanced service enablers such as presence or group management; however, the IMS standards do not specify how these applications should be developed. An AS communicates with S-CSCF and with HSS through Diameter-based interface.

Figure 2 - IMS Reference Architecture

The Media Resource Function (MRF) can be split up into the MRF Controller (MRFC) and the MRF Processor (MRFP). It provides media stream processing resources for media mixing, media announcements, media analysis, and media transcoding. Also important in IMS are the legacy concerns: the Border Gateway Control Function (BGCF), Media Gateway Control Function (MGCF), and Media Gateway (MG) are responsible for interworking the bearer between Real Time Transport Protocol (RTP)/IP networks and circuit switching networks. A Policy Decision Function (PDF) is also defined within IMS, which authorizes media plane resources e.g. QoS over the media plane. It is used for policy control and bandwidth management.

2.2. Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) Although IMS is a major step forward towards the network convergence vision of delivering any multimedia service over any network, it is still rudimentary in many aspects, such as coordination required between access networks in networked databases, admission and resource control. TISPAN, also ETSI sponsored, is in charge of addressing these convergence issues, aiming a fixed-mobile convergence environment. As illustrated in Figure 3, TISPAN (Release 1) architecture is based on the concept of cooperating sub-systems sharing common components. This approach allows the addition of future sub-systems and ensures that network resources, applications, and user devices are common to all subsystems. The IMS Core, which is closely based upon 3GPP IMS Release 6, is one of these subsystems. The Network Attachment Sub-System (NASS) and the Resource and Admission Control Sub-System (RACS) are two other relevant sub-systems, responsible for IP connectivity and QoS, respectively [7]. NASS provides address allocation, authentication and authorization functions, access network configuration and location management. RACS provides QoS control (including resource reservation, admission control and gate control), Network and Port Address Translation (NAPT) and/or Firewall (FW) traversal control

functionalities over access and core transport networks. Admission control involves checking authorization based on user profiles, Service Level Agreements (SLAs), operator specific policy rules, and resource availability within access and core transport. The interrelation between all these subsystems is the key advance inside the TISPAN architecture.

Figure 3 - TISPAN Reference Architecture

2.3. Open Mobile Alliance (OMA) The sought-for convergence has also implications for the top service layer of figure 1, as applications and services are many and diverse. Such applications may be able to monitor or control multimedia sessions and may be accessed through a session control protocol such as SIP. Thus, these services are closely coupled to the underlying network on which they are running, and therefore, a standard approach is required to deliver them across different networks. The Open Mobile Alliance (OMA) is a standardization entity responsible for specifying market driven service enablers that ensure service interoperability across devices, geographies, service providers, operators, and networks [4]. Examples of applications and services are presence, call conferencing, transcoding and billing. OMA specifies an OMA Service Environment (OSE) [7], which is a flexible and extensible architecture that offers support to a diverse group of application developers and service providers. OSE specifies enablers, which provide standardized components to create an environment in which services may be developed and deployed. The OMA enablers, the decomposition into these components, and the interactions between them comprise the OSE. Figure 4 illustrates the layered architecture of the OSE and OMA enablers.

OMA / 3rd Party Applications

Applications

Policy Enforcers

Digital Rights Management

Bindings

Bindings

Enablers

Billing Framework

Presence

Device Mgmt.

BCAST

Location

Operator / Terminal / Service Provider Resources

Figure 4 - OMA Reference Architecture

There are a large number of enablers defined or partially defined. Some have particular relevance for our aims, such as BCAST, Presence, Transcoding, Group List Management and IMS Utilization. The later facilitates OMA services and applications to make use of IMS. It is clear from the previous sections that NGN convergence is multifaceted requiring service convergence, session control convergence, architecture convergence and mobility convergence, and OMA enablers provide solutions to the service layer.

2.4. Multimedia Broadcast/Multicast Services (MBMS) Besides instrumental to IMS development, 3GPP also created the Multimedia Broadcast/Multicast Services (MBMS) [9], a sub-system standardized since 3GPP release 6. MBMS allows delivery of IP multicast datagrams to User Equipments (UEs) with specified QoS. On the control plane, it manages bearer service activation status of the UEs, outsources authorization decisions to a newly introduced Broadcast Multicast Service Centre (BM-SC), provides control of session initiation/termination by the MBMS user service, and manages bearer resources for the distribution of MBMS data. IP plays a key point role in MBMS, being used to identify the particular instance of the bearer service (which is composed by an IP multicast address and an access point name - network identifier) and to manage all MBMS multicast services. The Gateway GPRS Support Node (GGSN) serves as the entry point of IP multicast traffic as MBMS data. Upon notification from the BM-SC, the GGSN is responsible for setting up the required radio resources for the MBMS transmission inside the UTRAN/GERAN. The UTRAN decides on the appropriate radio bearer based on the number of users within a cell, prior to, and during a MBMS transmission. Mobility aspects are intrinsically supported in UTRAN/GERAN, but further mobility needs to be supported by the Serving GSN (SGSN), requiring the capability to store a userspecific MBMS context for each activated multicast MBMS bearer service (Figure 5).

Uu Content Provider

UE Gmb Um

BMSC

GERAN Gi

UE Iu UTRAN

GGSN Gn/Gp

Iu/Gb SGSN

PDN (e.g. Internet)

Figure 5 - MBMS Reference Architecture

MBMS is able to operate in two modes: broadcast and multicast (Figure 6). The broadcast mode works in a simplified manner, since it does not involve subscriptions management. It is composed by 5 phases: service announcement, session start, MBMS notification, data transfer and session stop. The service announcement is used to provide the UE with information on available MBMS services. The announced information includes parameters required for the service activation, such as service start time and content information, security parameters and associated delivery services. The session start phase is characterized by the trigger for bearer resource establishment for MBMS transfer. In the next phase - MBMS notification phase - the UEs are informed of forthcoming and ongoing MBMS broadcast data transfers. The following phase is the actual data transfer where UE receives the file or the streaming session announced. Finally, when the BM-SC has no more content to be delivered, the session stop phase releases the bearer resources.

Figure 6 - MBMS Broadcast and Multicast phases

The MBMS multicast mode works in more complex way than the broadcast mode. It considers higher level mechanisms for subscription management in order to optimize the distribution. For enabling such services, the multicast mode needs three more phases: subscription, joining and leaving. In the subscription phase, the UE must explicitly establish a relationship with the service provider in order to receive the MBMS multicast service via higher level mechanisms, such as a web portal or other defined service. Then, the UE, for each subscribed service, receives service announcements in a similar way to broadcast mode. Based on the received announcements, the UE may initiate the joining phase (typically through Multicast Listener Discovery – MLD or Internet Group Management Protocol - IGMP messages). The following phases – session start, notification, data transfer and session stop - are again similar to the broadcast mode. The main difference is that a UE is able

to perform a leaving procedure, informing the BM-SC that it no longer wants to receive data from a determined service.

3.

IMS-MBMS Issues

Converged

Architecture

Integration

MBMS, via BM-SC, provides the means to deploy multicast/broadcast based on 3G technologies as an independent system. It can work as a standalone technology since it has its own mechanisms of user accounting, charging, security, QoS and others. However, to be able to provide the same services in a heterogeneous environment, in a next generation network, MBMS needs to be enhanced. The integration of the functionalities of both MBMS and IMS could help on the development of a NGN architecture. The IMS-MBMS joined architecture aims to support the following functionalities: • IMS-compatible signaling for efficient multicast signaling, group management with context-awareness communities, dynamic multicast group address allocation; • Scheduling and congestion control with adaptive solutions based on feedback from the Radio Access Network (RAN); • Session management with RAN/bearer selection in a converged environment; • QoS support for multicast/broadcast services (beyond unicast and multimedia ones); • Transcoding strategies for provisioning of multi-layer services supporting usecases such as layered codecs and location-dependent transmissions. However, several issues on this integration need to be addressed to define such a converged IMS-MBMS architecture.

3.1. Architectural Issues As stated before, IMS seems to be the chosen technology for session control and, to a certain extent, also instrumental for architectural convergence. However, IMS does not support delivery of multicast/broadcast services, which reduces its scalability. If the MRF is enhanced to support multicast delivery, being able to either control a BMSC or directly multicast bearer services (MBMS or others), it would be possible to improve a service provider resource usage.

Figure 7 - IMS Architecture using MBMS bearers

A converged broadcast architecture based on IMS leads to the main approach of making IMS multicast technology enabled. In other words it must be possible to send multimedia content to a group of IMS users through a multicast capable technology as a bearer, where MBMS is the most prominent technology currently regarding multicast delivery. One first architectural option is thus to have a simple IMS and MBMS integration. An IMS and MBMS integration first architectural option is to allow IMS applications to use MBMS, preserving as much of its functionality and structure as possible. This is the approach in the 3GPP study item [12]: the architecture of which is shown in Figure 7, where it is presented the BM-SC as an entity inside IMS architecture to support MBMS bearers. This study group presents technical considerations and solutions into the facilitation of IMS services over multicast bearer services with a focus on the possible enhancements to IMS functionalities and relevant charging, security and service provision procedures. However, it considers the inclusion of BMSC in the IMS architecture without clearly specifying how to solve the duplicate functionalities and provide integrated interfaces. In the situation where there are a number of possible multicast-broadcast bearers, then the IMS must decide somehow which multicast-broadcast bearer to use. The decision must be based on the particular application, UE capabilities, multicast/broadcast access network and QoS parameters. This requires that the basic broadcast/multicast support functions are available at the service enabler layer and session control layer. For MBMS, this would mean that the functionalities of the BM-SC would be distributed over IMS entities and service enablers.

3.2. MBMS Functional Evolvement and Integration The BM-SC provides mixed data path and control management functionalities in one functional entity. Several of the MBMS functions defined are generic to any multicast/broadcast services. Good examples of this are security, service discovery, service provisioning and user management. When considering NGN convergence network, these functionalities need to be abstracted in a way that they can be reused by several technologies. Figure 8 presents the BM-SC functional structure within a UMTS network and covers the interfaces and protocols used. The centralized BM-SC comprises key MBMS sub-functions, described in the next paragraphs, along with integration and evolution issues raised by the current status of the standards. Membership Function

The BM-SC membership function provides authorization for UEs requesting to activate an MBMS service. This relates with Multicast join authorization, user membership management, time-related charging and subscription-related charging. This function manages bearer service membership functions and the subscription related information (user profiles), authentication and authorization of the user. However, it is not completely clear in the current release of the standards how and where user profiles are stored or how services’ authorizations are described. In IMS, the HSS is the master user database: it can further support the membership function role of BM-SC, holding authentication and authorization information to join a multicast group, user related information about services subscribed and others. This would require a clear definition of the functionalities expected both from IMS and MBMS, and the respective interfaces.

Figure 8 - BM-SC Functional entities

Security function

The BM-SC security function is responsible for service protection – limiting access to both broadcast and especially to multicast transmissions to registered subscribers. This is done by means of data ciphering and key distribution [10]. The MBMS Key Management function is used for distributing MBMS keys to authorized UEs. Before the UE can receive MBMS keys, it needs to register to the Key Request sub-function. Once registered, the UE can request missing MBMS keys from the BM-SC by indicating the specific MBMS key ID, and deregister when desired. MBMS User Service data protection is optional, only needed if requested by service announcement. The security depends directly from the General Bootstrapping Architecture (GBA) [11] function for authorization and acquisition of base key information. The scheme defined by MBMS is clearly dependent on 3GPP and only applies to MBMS technologies. In our vision, the security scheme should be further generalized in a way that it could be used by different access technologies. Therefore, one possibility for security convergence is to develop a specific enabler in IMS for key distribution, and have the actual data traffic encryption being done in the data delivery layer in the MRF function. Proxy and transport Function

The proxy and transport function acts as a gateway between core network and the transport layer. It manages routing of data and reservation of bearers across the transport layer to the registered GGSNs, while maintaining a clear separation between control layer (i.e. signaling) and transport/user plane (i.e. multicast payload). Also, it ensures QoS parameters agreed upon during session establishment by session and transmission functions. One main problem of the current MBMS architecture is that it assumes that the BMSC is completely in charge of policy control and resource reservation. However, it is advisable to consider integration of the PDF functionalities that already exist in IMS for media resource policy control with adaptations for multicast/broadcast service’s resource authorization decisions. . In [13] some service authorization issues are raised and hints about a possible solution using a PDF entity are provided, but not deeply pursued.

Session and Transmission Function

The Session and Transmission Function is the entity responsible for MBMS bearer session management, authenticating and authorizing external sources. It is also responsible for managing content repository and interacting with the content provider. Its interface with Content Providers is not defined in MBMS. It is unclear how content is authorized to be distributed in the MBMS network or how it is stored in case of non real time services. In IMS, Application Servers (AS) define the way it deploys hosts and executes services. This allows network operators or third party providers an easy integration and deployment of their value added services, such as group management, enhanced announcement services, or security support. Thus, it seems reasonable to have the interface with the Content provider either directly or indirectly through IMS AS. Furthermore, in the current version of the standards, the BM-SC is likely to be involved in scheduling transmissions and resource reservation (and release) for MBMS transmissions. A BM-SC is responsible for multicast broadcast service provisioning, so it might limit resource usage to some configured level, and reschedule file transmissions for a later time in case of high load of the network. It is also responsible to allocate resources to bearer services and provide the GGSN with transport associated parameters such as QoS and MBMS service area, thus supporting location-specific transmissions. As stated before, MBMS assumes that BM-SC is in charge of policy control and could clearly benefit with the integration of IMS PDF functionality for policy control. For streaming delivery, the BM-SC may collect Quality of Experience (QoE) reports. For download delivery, the BM-SC may collect reception acknowledgements and statistical reception reports, although these mechanisms are not clearly defined. IMS could perfectly manage the reception of these reports through a specific application server responsible for session management of multicast/broadcast services. This application server, after collecting this statistical information, could then control the BM-SC, MRF or other specific entity to efficiently use the available resources. The purpose of this approach is to not limit this mechanism to MBMS bearers. Service Discovery Function

The BM-SC also provides service announcements for multicast and broadcast MBMS user services, including the media descriptions specifying the media to be delivered as part of an MBMS user service (e.g. type of video and audio encodings). In addition, it also provides the UE with MBMS session descriptions specifying the MBMS sessions to be delivered as part of an MBMS user service (e.g. multicast service identification, addressing, time of transmission, etc.). These media and session descriptions are delivered by means of service announcements using IETF specified protocols, like Session Description Protocol (SDP) over MBMS multicast and broadcast bearer services. It is referred that an interactive announcement function may offer alternative means to provide service descriptions to the UE using HTTP or other interactive transport methods but they are not clearly defined. In MBMS no considerations are made concerning context or location awareness in service announcement. It is possible to consider that new emerging service enablers being developed for IMS, such as group management, would be adequate tools for service announcement, bringing location and context-sensitivity into MBMS.

4.

An evolved IMS – MBMS Architecture

The challenge towards a long term evolution of multicast/broadcast services is to merge this technology within a truly NGN architecture, IP-based. Current work within 3GPP Long Term Evolution (LTE) and System Architecture Evolution (SAE) is ongoing and is expected to develop further: it is expected to bring enhancements of packet switched technology to cope with rapid growth in IP traffic through a fully IP network with simplified network architecture and distributed control with heterogeneous access. Similarly, the work on a next generation IP-based converged network under TISPAN is also in progress. In these cases, the whole concept of group session inside MBMS needs to be rethought, as the transport layer may already support multicast capabilities.

Figure 9 - Evolved IMS - MBMS architecture

Taking the present status and trying to understand the basic premises of SAE, LTE and TISPAN, we developed and evaluated a possible architecture integrating IMS with MBMS over an evolved network. In this architecture we propose to have the MBMS BM-SC functions completely distributed among the existing network entities (a centralized BM-SC entity no longer exists). Also, the functions such as security, service announcement, QoS provisioning, are not kept specific to one access technology; they are generalized to cope with any access technology, and IP multicast is assumed as common transmission layer. In Figure 9 we propose a new layered design, mainly based on IMS, but we introduce more granularity to the picture: delivery plane is now divided in access and delivery. Access relates with access technology used by the end user to achieve access to the network; delivery concerns the converged IP layer. The service plane is also sub divided in application plane and service enabler plane. In the following sections, we explain in detail each plane considered in the devolved architecture and the way the existing BM-SC functions are distributed. Figure 10 presents a detailed network entity design. Access and Transport Plane

The access and transport plane is completely distinct from the one in the MBMS standards: an evolved UMTS packet core is now considered, where the GTP tunneling mechanisms to support mobility have been substituted by enhanced IP based multicast and mobility mechanisms. This trend closely follows the SAE evolution as defined in [15] and a similar architecture as been defined in [14] with support for multicast

mobility. One visible consequence of this evolution is that the IP packet network is now closer to the radio access network, which allows IP convergence closer to the user, reducing the access (technology specific) to a smaller area. Also, another important aspect is that this architecture is designed to cope with different types of access networks. It is possible to consider not only a 3GPP evolved packet core, but also other technologies such as WiFi, WiMax or DVB-H (the last one is very interesting in particular to multicast/broadcast services). The evolved packet network architecture includes an access technology dependent element, the PCEF (Policy Control Enforcement Function), to control the (technology dependent) allocation of resources, the mapping of QoS parameters, and the enforcement of charging and policy. Generic interactions with this entity are performed over the Gx interface as defined in [16] (however, [16] is still under heavy development 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 support to multicast bearers creation, allowing a user to join a multicast group, set multicast related QoS parameters, and provide generation and transmission of charging vectors for online or offline charging, among other functions.

Figure 10 - IMS and MBMS integration details

Media Delivery Plane

Transport and pre-processing of content take place in this layer. Therefore several Media Delivery Function Processor (MDFP) entities are designed. MDFP extends the MRFP defined within IMS. The MDFP, in combination with Media Delivery Function Controller (MDFC), provides the ciphering of media (broadcast/multicast security), error correction coding, mixing of different media streams and transcoding. MDFP is placed as a gateway between the Content Provider and the Evolved Packet

Core. In addition, it also handles the enhanced group management and session management delivery functions. There are several candidates for the protocol used between MDFC and MDFP, such as SIP or H.246/MEGACO depending on the flexibility of the required features. The interface between MRFC and MRFP needs also to be enhanced according to the implications over the control of multicast bearers. Control Plane

The developed IMS-based control plane consists of CSCF proxies, HSS, PCRF and MRF (constituted by MDFC and MDFP). The Policy Control Resource Function (PCRF) is introduced in SAE/LTE as an extension of the IMS PDF component for harmonization of admission, charging and QoS mechanisms. It is mainly responsible for QoS aspects, policy management and charging functions. From the Rx interface, it receives from the CSCF requests from different Application Functions (such as AS or UEs), through a Diameter based interface, for admission and authorization of calls. This interface is defined in [17]. However, SAE/LTE vision of PCRF is not yet multicast capable and needs to enhanced to cope with multicast/broadcast support. Our proposal is to enable the CSCF capability to request policy decisions to the PCRF entity for multicast/broadcast services announced by application functions. The PCRF entity also needs the support of an extended user database in order to obtain the user profiles for policy decisions. The HSS needs small enhancements to fulfill these functions. Joining of services is feasible with initial filter criteria placed in user profiles. The S-CSCF contains service-triggered information in the form of initial filter criteria. When the user equipment establishes a connection to our architecture, the S-CSCF transfers the corresponding user profile from the HSS. The user profile contains the subscribed service groups. Whenever the connection is set up, the S-CSCF executes service triggers and sends SIP messages to the group server in the application layer. These SIP messages result in service activation and thus allow service group delivery. Scheduling and resource control is an aspect of the MDFC (the enhancement of the 3GPP MRFC). MRFC provides services for conferencing, announcements to a user or media transcoding in the IMS architecture. To control the sources of content, the MDFC has to support Content Providers to deliver specific content to a specific unicast, multicast or broadcast address. MDFC functions mainly are reservation and administration of multicast addresses – e.g. allocating unused multicast address for every multicast delivery session, find an appropriate MDFP depending on users’ location and multicast, multicast/broadcast service scheduling. Service Enabler Plane

In SAE/LTE specifications no detailed information is given about the Service Enabler and Application Layer. Most of the features and enablers along with interfaces will be evolved from IMS and OMA specifications and architectures to function over an SAE/LTE network. In order to provide multicast/broadcast enabled services, we propose to define the MB-SE (Multicast/Broadcast service enabler) as shown in Figure 10 – some of these functions are already found in an early stage in the R6 architecture BM-SC. These include: • Security management functions including registration for key updates, service key updates; • Service description and service guide aggregation for 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 Statistics Collector is responsible for collecting and aggregating the status of both the Radio Access and the Core Network, storing and analyzing QoS reports. Hence, its output can be used by the Service Scheduling Management as basis for scheduling decisions. In addition, it enables the Session Management Function (and the subordinated M - Session Manager) to select either multicast or unicast transport. The scheduling functionalities in turn provide the Service Guide Aggregator with information about the calculated timeslot for each service. In order to support efficient multicast scheduling, the Service Scheduling Management depends on Group Management functionalities, e.g. identification and location of recipient group members. The Service Protection/Key Management entity is responsible for delivering service key updates (session keys or MSKs as in [10]) based on previous UE registrations to receive these updates. This is done in R6 within the BM-SC based on HTTP. In the proposed architecture it is suggested to use Subscribe/Notify allowing the UEs to register to receive key updates and acquire these updates when available from the BM-SC. Other BM-SC security functions are distributed across the IMS core (authentication) and the MDFP (ciphering and traffic key generation). • • • •

4.1.1.

Issues & Consequences for future convergence

The usage of this approach for future convergence presents some constrains and problems. The key point here is the increased integration and distributed implementation of the MBMS architecture and concepts into the IMS sub-system. From the point of view of 3GPP, this is actually a change into the existing deployment ideas: equipment manufacturers are now developing BM-SC and IMS boxes, mostly with low inter-relation. In fact, not even the simpler integrated architecture presented in section 3 is now supported in any implementation. The distributed BM-SC approach breaks this deployment structure, and impairs the evolution of existing/planned products. The impact on TISPAN is not less, unfortunately. TISPAN advocates a clear subsystems approach; here, IMS and MBMS seem to fit naturally. The distribution of the multicast/broadcast functionalities across the several entities breaks this approach, merging unicast and multicast services in a common platform. On the other hand, the proposed approach is more naturally adequate for a flexible environment, and specially to share the commonalities provided at the transport and control level. User personalization, media description, resource management and IP transport can be integrated, providing optimum service provision regardless of the type of service being provided.

4.2. Delivery Issues This section addresses some of the issues relevant for an integrated NGN environment.

4.2.1.

Scheduling/admission across RANs

Future NGN will have to cope with scheduling and admission problems across different RANs – and these problems will be more complex when entertainment media is being handled. Admission is always an issue associated with the user, through the HSSC and the PCRF, but network aspects are more complex than this. Considering traditional cellular environments, broadcast radio sub-carriers may (or may not) be allocated. This will depend on the interest/number of users currently in the cell. The PCEF will have to manage this process, inclusive considering the dynamic change of carrier, depending on the total cell available bandwidth for group communications, and on the total consumption at the moment. This considerably affects admission decisions, as algorithms will now need to consider these potential changes also. The problem may be even more complex as broadcast RANs are considered, such as DVB. Here, admission is immediate (a matter of allocating the user with the correct keys, at the MCast Enabler) but the scheduler needs to know that the UE has capability to receive information in such interfaces. Subscription is then not an immediate process (user subscribes the interface that is active), but a process where the interfaces able to receive the specific content are explicit mentioned. When discussing session mobility, this brings an added problem, in deciding which is the best interface to continue a session.

4.2.2.

Resource usage

The previous paragraph clearly identifies issues associated with resource management at the radio access. Changing streaming across technologies or changing the type of logical channel at the radio access may bring added efficiency to the network. Naturally, the PCEF needs to handle this, but when the capability of switching technologies becomes important (e.g. all devices have WiFi, 3G and DVB interfaces), a new concept for PCEF is required: cross-technology optimization needs to be in place. A further aspect of the problem is related with the wired-side optimization. Typically this is considered the “core”, but in most cellular systems, Base Stations (BS) are not directly in to the core, but are connected to this via a limited bandwidth line (often rented to a wired provider). This brings a clear incentive to distribute to each BS only the groups that are needed – and thus multicast tree optimizations at the transport level are also important. In our view, this is essentially handled at the IP level, and inherent to the whole process: the context management guarantees that required groups are subscribed at a given BS.

4.2.3.

Transcoding

The facilities of dynamically switching the delivery of entertainment media can be optimally exploited when content adaptation is present in the network. Delivery over a CDMA or WiFi channel, or a DVB stream, presents quite different technical problems, and is able to exploit quite different bandwidths. The content adaptation function in Figure 10 can be dynamically invoked to provide to the UE the stream coded with the best characteristics for the current carrier. The content provider will be oblivious of this, as transcoding can be dynamically provided as an added value of a true NGN. The proxy and transport function distributed at access and delivery layers (Figure 10) enables this feature for the converged architecture. While sending data to

the transport layer, delivery-proxy and transport function checks for the carrier in use and transcodes accordingly.

4.2.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 integration of multicast services in NGN handles access control in a similar way than unicast services, with the user profile being stored in the same entities (HSS), but now with an added support from PCRF for QoS support. Nevertheless, broadcast services (in RANs such as DVB) need a paradigm extension to handle access control through key management. Note that the access to this key is made through the “bidirectional” RANs, providing a simple and controllable mechanism to distribute these access keys. On the same token, information confidentiality (e.g. adult services cannot be transmitted in open channels in most countries) is also guaranteed by the same method, for broadcast RANs. When non-broadcast logical channels are used (such as a dedicated channel in 3G), confidentiality could be assured by the same mechanisms for unicast services (that is, thought link-level security): however, the potential session mobility that could happen at any instant as the user moves, argues in favor of retaining always the same key-management based security mechanisms for group services, regardless of aspects of radio resource management.

5.

Evolving Multicast Broadcast Services

The convergence of the multicast-broadcast services and IP-based environments, as proposed to be done in NGN, aims to open new business opportunities. Although many of these will depend on regulatory aspects of merging broadcast and telecommunication services, their significance for an open communications market will eventually lead to their emergence.

5.1. Multicast Services One of the areas where the integration of these two areas may be simpler to support is associated with all aspects of closed-group services being delivered in a heterogeneous network.

5.1.1.

Evolved group services

Currently groups are handled inside telecom operators mostly as a profile for certain customers, which have subscribed to different services. Our approach provides the flexibility for deploying much more complex intelligence in group service provision. Access to groups now requires a specific request (as before), but which can eventually be transferred to AS, or to the content provider. Group services can now go through specific logic, and provide different content to different users, depending on many aspects: transcoding of information according to the access network (as discussed above); selection of the content according to the user preferences (e.g. on transmitting a football match, the transmission may push different cameras to the user according to its team preferences – this can be done easily by transmitting multiple flows, accessible by different keys) or subscriptions (a premium user can have access to all the flows being transmitted from the game).

An advantage of our proposal is the fact that the specific method to deploy these features could be potentially different; however, for an optimum deployment in terms of wireless resource management, different multicast trees should be created inside the network, reaching only cells where those resources are needed.

5.1.2.

Key Service enablers

As discussed in the previous subsection, one of the main motivations to pursue IMSMBMS integration is to enable interactive group based and context aware multicast services. Also, discussed in section 4, in our proposed architecture some of the BMSC functionality is relocated at service enabler layer in the converged architecture; we present this ported functionality as an enabler called Multicast Broadcast Service Enabler (MB-SE). Figure 11 shows the structure of MB-SE and its interaction with other enablers provided by the converged framework. As shown, multicast services interact with other IMS-OMA enablers to carry out functions like scheduling, service discovery, charging and security. Content Provider

Multicast Broadcast - Service Enabler (MB – SE)

Device Management Group Management Enabler

Scheduling Management

Statistics Collector

Service Protection/Key Management

Service/Session Description

Key Distribution Function

Service Guide Aggregator

Key Request Function

Service Discovery Enabler

Session Management Function

Charging Enabler Security Enabler Presence Enabler

Session Management Enabler Other Enablers MB-SE

Converged IMS-MBMS Core

Multicast Specific

Figure 11 - Broadcast/Multicast Service Enabler – Functional Structure.

It should be made clear at this point that multicast transmission is a scenario made possible by this converged architecture with added flavors of group based and context aware services. Therefore, for an end-to-end multicast transmission model, our MBSE enabler makes use of other enablers specified in 3GPP and OMA specifications

5.1.3.

Context-aware Group Management

This optimality of tree creation for streaming distribution creates an added dimension to group services, most especially to subscribed services related to information. Context (such as location) may lead to the creation of different groups: a video-server may provide information about local points of interest, according to location (e.g. all restaurants may have a short promotional video being distributed in the “food information service”, and depending on the location, users will be allocated to different multicast groups, and thus receive different streams). This can be also different depending on other context aspects, such as e.g. current weather (receiving

video promotion about a nice café in the middle of the park is not probably very effective during a thunderstorm). On the other hand, users may also push their content locally – the development of environments like youtube is a good indication of this interest. Communities – in the sense of groups of interrelated users – can be dynamically supported, as long as a group management service is in place. This service, providing simply key management and traffic rendezvous point, may allow closed groups to be created, and user-originated content to be distributed inside that group.

5.2. Broadcast Services Broadcast services, in its more basic understanding, means the same content to all users, regardless of the user. Nevertheless, broadcast services also benefit from synergies inside NGN.

5.2.1.

Evolved Broadcast services

If the content of broadcast services aims to be the same to all interested users, there are two aspects that benefit from an individual separation: i) advertising; ii) content authorization. On the first point, the integration of broadcast services inside NGN allows for a much more effective exploitation of advertising. Today, marketing already positions its publicity in different channels, at different times, according to the presumed user stratification. It seems obvious in our structure to allow advertising time to be finetuned to users, depending on location, context, or even its preferences. Broadcasters would then resort to multicast groups during advertising time. The second point is associated to content authorization. Broadcasters are having increased limitations on content distribution according to issues as violence, profanity or adult content. With an integrated environment, all these content types could be transmitted without restrictions: viewing is individual – mobile devices are not for common viewing, and as such the user may choose to see whatever content he wants, as if the transmission is made in a paid-channel. Age restrictions can be placed at the subscription time, with users being allowed (or not) to access restricted content based on their age.

5.2.2.

Key Service enablers

In terms of functional components and enablers required, broadcast can be seen as a subset of multicast transmission. Referring back to Figure 11, for broadcast transmission, key service enablers would be the same apart from key management, key distribution and membership functions which are not required for a broadcast transmission setup.

6.

Future Work & Conclusion

This paper presents an architecture which integrates group communications in a NGN environment. This architecture is shown in an evolutionary way, with a first instantiation simply bringing the IMS and the MBMS sub-systems working together. In a second more evolved approach, resorting to an All-IP concept, our architecture is devolved in terms of deployment, leading to a distribution of all group-functionalities by different entities. This integrated approach exposes new approaches to group and broadcast services, where the resource usage efficiency of broadcast/multicast techniques can be merged

with individualized interests, creating new and more efficient paradigms both for network and content providers.

7.

References [1] ITU Focus Group on Next Generation Networks (FGNGN) http://www.itu.int/ITU-T/ngn/fgngn/ [2] Telecoms & Internet converged Services & Protocols for Advanced 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 and Management“ [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 Multimedia Broadcast/Multicast Service (MBMS) " [11] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture". [12] 3GPP TR 23.847: “Enhancements to IMS service functionalities facilitating multicast bearer services” [13] Ogunbekun, J.; Mendjeli, A., "MBMS service provision and its challenges," 3G Mobile Communication Technologies, 2003. 3G 2003. 4th International Conference on (Conf. Publ. No. 494) , vol., no.pp. 128- 133, 25-27 June 2003 [14] Leoleis, G.; Dimopoulou, L.; Nikas, V.; Venieris, I.S., "Mobility management for multicast sessions in a UMTS-IP converged environment," Computers and Communications, 2004. Proceedings. ISCC 2004. Ninth International Symposium on , vol.1, no.pp. 506- 511 Vol.1, 28 June-1 July 2004 [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 Gx reference point” [17] 3GPP TS 29.214 “Policy and charging control over Rx reference point”