Design of NGN Mobile Multicast Group Service Enablers Madiha ZAFAR1, Nigel BAKER1, Ahsan IKRAM1, Meir FUCHS2, Filipe PINTO3, Adel AL-HEZMI4, Michael KNAPPMEYER5, Telma MOTA2 1
Univeristy of the West of England, Frenchay Campus, Bristol, BS7 0PH, United Kingdom Tel: +4411732831776, Fax: +441173282734, Email: {madiha.zafar, nigel.baker, ahsan.ikram} @uwe.ac.uk 2 Bamboo Media Casting, Hasharon Road 12, P.O.B 5035, Kfar-Saba 44150, Israel Tel: +972544470347, Email:
[email protected] 3 PTIN, Rua Eng. José Ferreira Pinto Basto, 3810-106 Aveiro Portugal Tel: +351234403200, Fax: +351234424723, Email: {filipe-c-pinto, telma} @ptinovacao.pt 4 Fraunhofer Institut FOKUS, Kaiserin-Augusta-Allee 31, 10589, Berlin, Germany Tel: +493034637109, Email:
[email protected] 5 University of Applied Sciences Osnabrueck, P.O. Box 1940, 49009 Osnabrueck, Germany Tel: +495419693453, Fax: +4954196913453, Email:
[email protected] Abstract: Telecommunications industry has constantly enriched user communication experience by adding services in a service orientated approach. These services are supported by end-to-end design and integration of functions within the infrastructure. Convergence of mobile and fixed telephone systems, computer network (Internet) and broadcast infrastructure has motivated the telecommunications industry to design services such that they are capable of operating across many access networks. The difficulty is that many of the services are deeply entwined within a specific network. 3GPP (Third Generation Partnership Project) MBMS (Multimedia Broadcast and Multicast Service) is a typical example. Providing multicast group communication is a common service required of any network. This paper discusses how the 3GPP MBMS service was deconstructed and implemented as OMA (Open Mobile Alliance) type enablers suitable for NGN (Next Generation Networks) together with issues that emerged as the work progressed. It also includes the design of new features to support ad-hoc groups, context aware groups and user generated group content. Keywords: Mobile Broadcast/Multicast, Context-Aware, IMS, MBMS, Next Generation Networks, Service Enabler
1. Introduction Service orientated architectures and service orientated computing have stimulated much debate in computing and business as a new way of designing IT systems. In contrast the telecommunications industry has had a long tradition of using a service orientated approach to enrich user communication. These services, be it call forwarding, SMS messaging, location or TV broadcast have been designed to integrate efficiently within a specific network. Functions are embedded end-to-end within the infrastructure in order to provide an optimised user service tuned for the characteristics of a particular network type. The rapid adoption of digital IP communication across all sectors of the telecommunications industry means that many of the core network characteristics are now similar. The access part of networks particularly radio access will always have very different characteristics but the core will be based on Internet protocols. The industry goal therefore is to stimulate all sectors to converge towards a common core network so that users can obtain any service across any type of access network. There are ongoing activities by several organization
bodies such as TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks), 3GPP, OMA in order to achieve this. The work presented in this paper is performed under EU-IST project C-MOBILE [1] and discusses the design experiences of re-engineering 3GPP MBMS into a next generation network common service capable of providing advanced group services across any type of access network. The remainder of the paper is organised as follows. Section II briefly analyses 3GPP MBMS and identifies the requirements of a common framework to support advanced multicast group services. Section III describes the design of a framework compatible with TISPAN NGN architectural principles. Section IV presents the design and implementation of the key service enablers. Finally, Section V draws a summarising conclusion and discusses future work.
2. Problem Analysis & Architectural Design The 3GPP MBMS reference architecture [2] is illustrated in Figure 1. UMTS (Universal Mobile Telecommunications System) cellular networks offer a unicast point to point communication service but MBMS upgrades this to allow true multicast/broadcast service across the air interface. With the increase in multimedia traffic the bandwidth saved by sending one data stream to many users is an attractive proposition. The service also facilitates the creation of group applications. The functionality to support this service is provided as software upgrades to the network components including handset as well as a new server box called the BM-SC (Broadcast Multicast Service Centre). One of the challenges of the project was to analyse and reengineer this common service so that multimedia multicast applications and content could be offered via any type of network in line with the TISPAN NGNs. User service provision and delivery functions are managed by the BM-SC shown in Figure 2. The BM-SC provides service announcements for multicast/broadcast MBMS user services. It makes transport-associated parameters, such as QoS and service area, available to the GGSN (Gateway GPRS Support Node) and is in charge of initiating and terminating MBMS bearer resources. The BM-SC sends MBMS data and takes into account the integrity and confidentiality protection of the information. The user services are mainly based on streaming and content download. Notice that some interfaces, for example between BM-SC and Content Provider (CP), are not defined. The radio access network part of the MBMS service offers a multicast/broadcast bearer service which must be controlled and accessed. The IMS (IP Multimedia System) [3], a key technology in the TISPAN network convergence architecture, is able to do this.
Figure 1: 3GPP MBMS Reference Architecture
Figure 2: BM-SC Functions
3GPP Release 5 introduced IMS as an extension of the UMTS architecture. It was developed to establish, control and terminate multimedia delivery sessions over different access technologies. The main gains of having this additional subsystem are threefold: IMS provides Quality of Service (QoS) in the user plane, since it is aware of the service requested by the user; knowing the exact service, the operators may also improve their charging schemes for multimedia sessions; finally, IMS allows integration of different services. IMS was designed to deal with point-to-point connections so for example, within a multiparty conference, a point-to-point connection between the media server and each user is created. What we require is the creation of a multicast radio access bearer (for example MBMS, DVB-H (Digital Video Broadcasting - Handheld) or WLAN) connecting the media server to all the participants. This is done by essentially wrapping the multicast bearer in an IMS SIP (Session Initiation Protocol) session. IMS can therefore be viewed as an overlay control layer which provides access to any unicast, multicast and broadcast technology. A thorough investigation and analysis of various possible IMS-MBMS integration architectures and signalling frameworks was carried out. Similar comprehensive analysis was conducted to identify common service enablers. The details are documented in [4] and [5]. In order to enable IMS entities to support multicast/broadcast transmission, numerous network entities are enhanced. An illustration of the key functional decomposition is presented in Figure 3. The functions illustrated as yellow coloured boxes represent the distributed BM-SC functionality at various IMS layers and amongst various IMS entities. The SEP (Service Enabler Plane) and its constituents will be discussed in the next section. Application Plane
Ut
Ut
APIs
Service Enabler Plane
Ut
Content Mgmt Enabler
Service Announcement Enabler
Service Protection Enabler
Context-based Group Mgmt Enabler
Session Management Enabler
Service Scheduling Enabler
HSS
IMS-based Control Plane
Cx/Dx
M* -Membership
User Plane
Content Manager
ISC/Ma
Sh/Dh
Gm
Ut
P/I/S-CSCF
M*- Session & Transmission
Gq/Rx
PDF/PCRF
Gm
MDFP Controller
MDFP Location
M* - Session Manager
Congestion Controller
Content Adaptation
Session Scheduling Controller
Media Delivery Function Controller (MDFC) or MRFC
Go/S7 Gi
Gmb
Gmb’
Mb
Delivery Session Manager
Media Delivery Function Processor (MDFP)
Delivery Group Manager
M* Transport
Media Processor/Transcoder
Mb
Streaming and Download Source
MDFP or MRFP
Media Delivery Plane Gi Evolved Packet Core
M*- UE BS Context Managment
M*
M* - Proxy And Transport
Access and Transport Plane
Distributed BMSC Functionality (M - Multicast)
Figure 3: Evolved MBMS: IMS Integration and Supporting Service Enablers
Content Providers Plane
3. Multicast Service Enablers The vision of the service orientated architecture community is to compose applications and complex services by combining existing fundamental basic services [6]. The goal of the OMA is similar in that it identifies and defines in a technology neutral format, the fundamental telecommunication services or service enablers. The approach taken therefore was to deconstruct the MBMS service and re-construct as a set of new and existing OMA enablers, while taking into account the emerging TISPAN architecture. Within the SEP (see Figure 4) several service enablers have been identified namely SAE (Service Announcement Enabler), SPE (Service Protection Enabler) and SME (Session Management Enabler) along with CGME (Context-aware Group Management Enabler) and SSE (Service Scheduling Enabler). Other enablers may be required and some have already been standardized by the OMA for example, Presence and Location. It is very important to distinguish between the OMA Broadcast Enabler and the work presented here. This work concentrates on defining enablers that will support multimedia multicast group services where content will be based on social groups and context. In contrast to broadcast which is concerned more with TV and radio channel type content. Nonetheless some defined broadcast enablers such as the ESG (Electronic Service Guide) can be used in conjunction with service announcement. A brief discussion of each enabler now follows.
Figure 4: The Multicast Service Enablers
3.1 Content Management Enabler (CME) The CME serves as an interface enabler between a service provider and a CP (Content Provider). It provides control and policing of the type and amount of content allowed as part of a service. The CME is responsible for assigning a unique identifier to each content and service. In addition the CME can be extended to support content discovery based on the content description provided by the CP. This function can be used to intelligently identify appropriate content by the network, especially for context-aware multicast groups. Therefore, the CME maps public identifiers to one or more private identifiers for security considerations. It will manage the available content and services by maintaining a map between internal and external identifiers. The CME is the only contact point for the CP. All requests from the CP side are answered by the CME. Further, the messages to trigger the delivery of content on behalf of a service are sent by the CME to the relevant CP. By
utilisation of the interface between CME and CP, the CP is able to add new contents to the service provider, delete content and push content to a specific group. 3.2 Session Management Enabler (SME) The SME is the contact point for the end user. At the SME the users register to the service they are interested in receiving. All signalling flows between the SEP and the end user are handled by the SME. Therefore, it manages session start and session stop signalling. Bearer selection is another responsibility of the SME. The SME decides to use a multicast or broadcast bearer, depending on the registered user to a service, if the service provider has not defined a fixed bearer. And based on the selection, appropriate address allocation is ensured by this enabler. From an OMA perspective, the SME interacts with the ‘SIP connectivity layer’ which comprises the basic SIP proxy and registrar function. IMS offers SIP infrastructure capabilities in the network and in the UE (User Equipment) via the SIP connectivity logical layer. 3.3 Context-aware Group Management Enabler (CGME) The CGME is introduced at the service enabler plane to support group management functionality within the IMS-core. It is responsible for group management tasks including group creation and deletion, group updates and group membership rules while keeping it in line with the group’s dynamic profile, based on context information. The enabler supports three types of multicast groups; service-initiated multicast group, user-initiated multicast group and network-initiated multicast group. Service initiated multicast groups are the typical subscription-based service groups currently supported by MBMS. The enabler also supports user-initiated multicast service groups where the user not only specifies the group but it is the source of multicast data as well. The most innovative kind of group support by CGME is the network-initiated service multicast group. These groups are identified and created by the service enabler based on dynamically changing user context. The network initiates session establishment for such groups opportunistically. 3.4 Service Scheduling Enabler (SSE) The SSE is responsible for organising the optimal schedule (order) of service/content deliveries in order to efficiently utilise the available resources in the Core Network and Radio Access Network (RAN). For this purpose it takes into account the spatial distribution of the users among the cells (to the extent possible) as well as the current and the estimated RAN capacity. It further differentiates the various types of service (carousel, streaming, file download) and considers the defined QoS requirements (jitter, delay, bandwidth). The SSE triggers the delivery of service data (content) by delegating the SME to initiate the session. 3.5 Service Announcement Enabler (SAE) User service announcement refers to methods for MBMS service providers to announce the list of available MBMS user services and user service bundles, along with information on the user services, to UEs. The SAE provides service announcements describing a service to the end-user and is responsible for distribution of a service guide (ESG or EPG) to the endusers. The information received includes required description of the service, any relevant information to the service, possibly the required and optional terminal capabilities for consuming the service and most importantly an address to be used to activate the service.
3.6 Service Protection Enabler (SPE) Service protection limits access to both broadcast and multicast service transmissions so that only the registered or subscribed group members can access the service. The SPE is responsible for registering UEs to receive MBMS key updates, encrypting services and managing service key updates. User authentication is done by the S-CSCF (Serving Call Session Control Function) entity in the IMS core. Once a UE is authenticated and subscribed to a service group, it can register to the key request function of the SPE. Once registered, SPE then sends key update messages (MIKEY/UDP) to the SPC (Service Protection Client) within the UE. One major functionality split for MBMS security is ciphering vs. key distribution. While ciphering deals with media itself, key distribution and specifically service key distribution (MBMS Service Key: MSK) takes place on a one-onone basis between SPE and each UE. A possible architecture for MBMS security would therefore have the actual ciphering take place at media delivery plane while the service key distribution is being driven by the SPE.
4. Example Multicast Service Enabler Interactions The service enablers play a key role in provision of group services over IMS using multicast/broadcast bearers where appropriate. As previously discussed, the BM-SC functionality is split amongst multiple service enablers. This section describes one interesting interaction to give some understanding of how they collaborate to provide a service. The use case illustrated in Figure 5, targets context-aware multicast services. Dynamic multicast groups are identified by the network based on the user context. Using the context information, the network discovers (using the CME) relevant content.
Figure 5: Context Based Multicast Use Case
1. 2. 3. 4. 5. 6. 7. 8. 9.
Using a notification model the Context Server passes context information to the CGME. The CGME creates a dynamic group and adds users based on their context information. The CGME then requests relevant content from the CME. If the relevant content is not available, the CME requests the CP. The CP responds back, either with the relevant content URI, or initiates a content registration process or declines the request. The CME responds back with either the service ID or declines the request. CGME then requests the SME to invite the context-based members to join the group. The SME sends session establishment requests to the group members. The users respond by either accepting or declining the request.
10. Depending on the number of willing users and the unicast-multicast selection mechanism, SME decides transmission mode and sends appropriate SDP (Session Description Protocol) to the users. 11. The SME also informs the CGME about the actual number of users in the group. 12. If content is not available at the MDF, the SME sends a delivery request to the CME. 13. The SME manages the delivery parameters at the media delivery layer. 14. The CME acts as a back to back agent and forwards the request to the CP. 15. The CP starts content delivery. 16. The media delivery function then delivers the service to the user(s).
5. Multicast Service Enabler Test Bed Framework A test bed has been developed to further evaluate the function and performance of the multicast group enablers. The set-up and how it maps on the above concepts is best described in an illustration (see Figure 6). The OpenIMSCore [7] is 3GPP IMS compliant. It provides a set of call session control proxies, an Home Subscriber Server (HSS) and a framework to support, host and manage Application Servers (ASs). Glassfish [8] is a J2EE based enterprise services creation, development and hosting environment. Sailfin [9] is the add-on to Glassfish that enables the container to host and manage SIP servets, Enterprise Archives (EARs), Enterprise Java Beans (EJBs) and Message Driven Beans (MDBs). Enablers are designed using servlets and beans to expose well defined modular interfaces. Clients are being developed for the Nokia N800 and the SIP stack used is Sofia SIP [10]. For media component, VLC [11] and Open Flute are being used. This system prototype is in its final stages of integration and testing.
Figure 6: Multicast Service Enabler Test Bed Showing Tools & Technologies
6. Conclusions One of the most interesting conclusions of this work is the power of IMS to integrate different access technologies. Essentially the MBMS radio access bearer was wrapped up in
a SIP session and unified in an end to end service delivery. A second observation is the potential capability of IMS to support a service orientated architecture. However a major difficulty faced when developing fundamental service enablers is to design them in such a way that they can be combined with other services and/or service enablers to produce more complex and rich applications. The enablers in this work satisfy many use cases and applications but in the test bed demonstrator the execution logic has been developed within the enablers. What is required is a standard mechanism to dynamically compose stand alone enablers on reception of a SIP message. This orchestration of application services and enablers is similar to parallel and distributed programming, requiring synchronisation, mutual exclusion and partial ordering. Scripts describing partial ordering and interaction logic could be stored in the service repository. Dynamic composition can then be achieved by retrieving a script for a particular service and executing it. The execution thread and service composition will vary depending on user profiles, service profiles and information in the SIP message. The Service Orientated Computing community use XML-based process standard definition languages for orchestration the two most well known examples are Business Process Execution Language (BPEL) for Web Services and Choreography Description Language (WS-CDL). There has been much discussion recently on the need for such a scripting language and standard execution mechanism for telecommunication service delivery platforms [12][13] including a work study item in 3GPP [14]. The execution mechanism is often referred to as a Service Capability Interaction Manager (SCIM), service broker or service dispatcher. There is also some debate as to where this functionality should lie as it could be embedded within an AS, outside an AS or could be embedded in the SCSCF. The former two options are where we would like to see it. Finally our work with context aware groups has identified that the IMS service environment although not fully defined does show particular promise in supporting context aware applications. Any architecture which supports context aware services must be capable of adapting to changing context and its infrastructure must be ubiquitous itself. IMS based on SIP and internet protocols and incorporated into mobile communication networks is gradually achieving this status.
Acknowledgment This work was performed as part of WP4 EU-IST project C-MOBILE (Advanced MBMS for the Future Mobile World) (http://c-mobile.ptinovacao.pt) under the contract IST-200527423. This project is also working on RAN enhancements for MBMS.
References [1] [2] [3] [4] [5]
C-MOBILE project web page: http://c-mobile.ptinovacao.pt 3GPP TS22.146, “Multimedia Broadcast/Multicast Service; Stage 1”, Rel. 6 3GPP, TS 23.228, “IP Multimedia Subsystem; (stage 2)”, Release 7, October 2006 C-MOBILE D4.2 (2007) Draft Specification & Requirements of Enhanced Core Network Elements Ikram, A., Zafar, M., Baker, N. & Chiang, R. (2007) IMS-MBMS Convergence for Next Generation Mobile Networks, NGMAST, Cardiff, UK [6] Service Oriented Architecture, http://en.wikipedia.org/wiki/Service-oriented_architecture [7] Magedanz, T., Witaszek, D. & Knuettel, K. (2005) The IMS Playground @ FOKUS – An Open Testbed For Next Generation Network Multimedia Services, 1st Intl. Conf. on Testbeds & Research Infrastructures for the Development of Networks & Communities [8] Glassfish (https://glassfish.dev.java.net//) [9] Sailfin (https://sailfin.dev.java.net/) [10] Sofia SIP (http://sofia-sip.sourceforge.net/) [11] VLC Player (http://www.videolan.org/vlc/) [12] Gourraud, C. (2007) Using IMS as a Service Framework, IEEE Vehicular Tech Magazine, 2:1, March [13] Michael Palmeter (2006) http://dev2dev.bea.com/blog/mpalmete/archive/2006/02/service_capabil.html [14] 3GPP TR 23.810, Study on architecture impacts of Service Brokering, Release 8
