Personalization-Based Optimization of Real-time Service Delivery in a ...

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

Personalization-based Optimization of Real-time Service Delivery in a Multi-Device Environment Marcus Q. Kuhnen, Daniel Kraft, Anett Sch¨ulke, Jochen Bauknecht, Johannes H¨aussler, Mario Lischka Network Research Division NEC Laboratories Europe, NEC Europe Ltd. Heidelberg, Germany Email: [email protected]

Abstract—The success of future NGN services depends on the ability to adapt and personalize service delivery according to the user’s context as well as service and device capabilities. Personalization includes not only respecting explicit user preferences, but also offering optimized multi-device communication. Flexible handling of multiple devices as well as multiple sessions is an increasing demand in the ubiquitous networking environment. In this paper, we describe how user preferences and device capabilitiy profiles for multiple devices can be managed and used for personalization. We integrated these methods into our earlierproposed Personalized Communication Controller (PCC), a Service Delivery Platform component for optimiziming multi-device communication through real-time decision-making. Information about related standardization efforts complements the paper.

I. I NTRODUCTION In the future service market, a high degree of customer satisfaction in service delivery cannot be achieved if only quality of service, availability of connection and bandwidth are taken into account. While pricing and quality matter (as always), trend analyses show that personalization plays a major role in the success of future services. Personalization is a feature of ever-growing relevance for online web and real-time services, manifested in different ways and contexts, addressing a variety of technologies. Early studies conducted in 2001 for the increasing web services market [1] evaluated the value of personalization for online services and analyzed available technologies and challenges relating to gathering and using user information. Recent studies on the value added for future services emphasize that personalization is the key concept for providing market differentiation [2]. Fig. 1 displays the results of a survey concerning the most important aspects of services and product manufacturers [3]. According to this, personalization is certainly a topic with high potential for future businesses. A characteristic of today’s communication is an increasing device diversity and multiplicity. Service features as well as device specialization are pushing the number of devices belonging to a user. Device capabilities differ between devices, and some devices are more adequate for receiving certain types of services than others. The convergence of fixed and mobile networks into the NGN allows to use a unified control layer for users connecting to the network, covering all the different access methods. Therefore, it is important for service delivery to take the capabilities of all the available devices –

fixed as well as mobile ones – and the possibility of multiple simultaneous sessions into account. This kind of adaptation to a user’s personal set of devices and his preferred way of using them is also a form of personalization. In the future, Service Delivery Platforms (SDP) will be important for the fast and flexible creation and delivery of an increasing amount of services populating the so-called long-tail service market. Personalization techniques must be integrated into SDPs in order to facilitate service differentiation for current as well as future services. With current personalization techniques, any adaptation of services is taking place within single services. Within that scope, sophisticated ways for service personalization including multiple devices are being discussed [4], [5]. However, personalization across different services, respecting the user’s devices, context, and preferences, as well as service requirements, is not considered. We have already proposed a mechanism for SDP-based personalization and optimization of communication paths in multiple device environments [6]. This user-centric approach allows for network-based, service-unspecific and dynamic personalization and is especially targeting capability interaction resolution in the user’s personalized service delivery space. In this paper, we explore further on the specifics for user preferences and multiple device aspects for personalized service delivery. Sections II and III provide an overview of the concepts of personalization, device capabilities, and related

Fig. 1.

Increasing demand for personalization of services and products [3]

978-1-4244-2948-6/09/$25.00 ©2009 IEEE

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

standardization activities. Our modeling of user preference and device capability profiles is described in section IV. Section V outlines an example scenario where our approach can be applied, section VI gives some details about our prototype implementation, and section VII concludes the paper. II. D EFINITIONS AND BASIC C ONCEPTS One means of realizing personalization are user preferences. User preferences are settings that a user can make explicitly in order to customize and personalize the services he is using for receiving a unique and personalized experience. User preferences should be accessible via standardized interfaces and protocols that allow to create, modify, read, and delete preferences. These interfaces should use a generic data model and be independent of service-specific structure and semantics of the preference data. Because services may be provided by different parties, service providers must have access to the subset of a user’s centrally managed preferences that relate to the service they provide. Otherwise, each third party service provider must also provide an interface for managing user preferences that are managed with the service. Device capabilities are the (hardware and software) characteristics of a device, as provided by its manufacturer. Most importantly, they determine whether and how a device can handle certain types of media. III. S TANDARDIZATION Personalization through some form of user preferences is tackled in a number of standardization efforts, some of which will be examined shortly in this section. A. OMA Converged IP Messaging (CPM) One quite comprehensive approach is that of the Messaging Working Group of the Open Mobile Alliance (OMA), which is currently in the process of standardizing communicationrelated user preferences for the Converged IP Messaging (CPM) Enabler. It is meant to become a messaging framework that includes intermediate and deferred messaging as well as session-based messaging, allows the use of various media types, and generally aims to consolidate common functionalities of existing messaging services. While itself being designed for all-IP networks and communication systems and especially for the IP Multimedia Subsystem (IMS), it also provides the functionality for its users to communicate seamlessly with the users of non-CPM communication services such as SMS and MMS. From the user’s point of view, CPM gives an improved experience e.g. by having a single user interface for different forms of messaging, a single identity for messaging across multiple devices, and a single address book accessible from all devices. The personalization of the offered services through the use of user preferences is an integral part of CPM. Version 1.0 of the CPM enabler is aimed for completion by September 2009. This and the following sections are based on draft versions of CPM standardization documents [7]. The CPM enabler makes use of other building blocks, like the Converged Address Book (CAB), the XML Document Management (XDM), and the Presence enablers.

Fig. 2.

User Preference Profile structure and device assignment

The CPM architecture contains a special user preferences component, which is accessible via interfaces using the protocols XCAP and SIP (see Sections III-D). The CPM Client stores preferences there, and the CPM Conversation Server (the main component of the CPM Enabler) retrieves them in order to enforce them. It is under discussion to include this component’s realization into the XDM enabler. B. CPM User Preference Profile Concept CPM user preferences are managed within User Preference Profiles. Each profile holds a complete set of settings for all defined user preferences. The user can create multiple profiles, e.g. according to particular situations: being at home, in the office, in a meeting, etc. He can select which of his profiles should be active for each of his devices, for particular addresses, or for combinations of both. This selection can be changed at any time. As an example, Fig. 2 shows the situation of a user with three devices, two of which use the same profile, while the third is just switching from the “office” to the “travelling” profile. The preference settings inside each profile can also be changed at any time by the user, and such changes instantly affect all the devices and addresses that have that profile as their active profile. Some possible use patterns of the profile concept include: • The user has just one profile for all devices and occasionally changes some parameters. • The user has different profiles for different devices and generally leaves that assignment as it is. • The user switches between different profiles on a single device, depending on circumstances. C. CPM User Preferences Some terms are used specially in CPM: A Conversation represents a “live” information exchange and is constituted by any number of Messages and Sessions. A Message is information of a discrete nature that can contain several pieces of discrete media (e.g. text, images, audio-clips, video-clips); it can be sent within or outside a Session. A Session represents a logical connection between two or more users established for a finite duration. In a Session, users can also communicate using continuous media that need a logical connection to be

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

set up and maintained between CPM users. It is assumed that each Conversation holds at most one Session at a given time, but a user can participate in several Conversations in parallel. Authorized users can capture and store the information that they have been exchanging during Conversations (Messages as well as continuous media from Sessions) as Threads in the network-based storage that is part of the CPM service. Stored Messages and media that come from the same Session form a Session History. The requirements for the CPM Enabler [7] mention a considerable number of user preferences that are to be taken into account for personalizing CPM services. These cover e.g. message and session handling (for the user being present as well as absent), media handling, (automatic) storing of Messages, Session Histories, and Threads in network-based storage, and multi-device handling (e.g. subsets of devices to deliver particular types of messages or media to). D. XML Document Management (XDM) CPM User Preferences Profiles are to be represented by XML files which are stored using the XML Document Management (XDM) Enabler. The choice of the active profile(s) is expected to be stored there as well. The XDM Enabler is generally used for managing userspecific service-related information, especially for IMS services, in the network. XDM specifies how such information is represented in well-structured XML documents. For document management, XDM uses the XML Configuration Access Protocol (XCAP) specified by the Internet Engineering Task Force [8]. It defines a convention for describing elements and attributes of XML documents as HTTP resources having HTTP URIs. This way, the HTTP GET, PUT, and DELETE methods can be used for various XML document manipulation operations like retrieving, adding, and deleting elements or attributes. In addition to standard XCAP, the OMA XDM specification [9] defines limited search capabilities using HTTP POST requests. For the notification of XDM Clients about changes to particular XML documents, the XDM specification makes use of the standard SIP event notification mechanism [10] and the IETF-defined xcap-diff event package [11]. The document format for storing CPM User Preference Profile in the XDM is not specified yet. E. Shared XDMSs for generic XCAP Application Usages In order for XDM-stored documents to be used by applications, application-specific conventions are defined by Application Usage specifications, including e.g. XML schemata for structure and constraints, or well-known URIs to bootstrap access to the data. The latest XDM enabler specification describes six Application Usages which can be reused by multiple enablers and allow e.g. the storage of group lists, user access policies, and list of URIs. One of these, the Shared Profile XDMS, specifies a User Profile document, which however does not substantially foster

personalization because it mostly contains name and (communication and postal) address data; the only “freestyle” elements are currently a freetext description of the user, a list of the communication abilities for human consumption, a list of hobbies, and a list of favorite links. An additional Locked User Profile document can only be created by the service provider on behalf of the user and contains only the “authenticated” birth date of the user, which is useful for agerestricted applications. The Shared Profile XDMS supports searching for User Profile documents matching certain criteria as well as extracting the user’s address and other information. F. Composite Capabilities / Preferences Profile (CC/PP) The Composite Capabilities/Preferences Profile is a system for expressing device capabilities and user preferences developed by the Device Independence Working Group of the World Wide Web Consortium (W3C) [12]. It is based on the Resource Description Framework (RDF), a general-purpose XML-based metadata description language, which allows to associate properties with resources. In RDF, properties and resources can be freely defined and organized in a class hierarchy. Classes are identified by URIs and therefore externally defined classes can easily be reused. The CC/PP specification defines profiles, profile components, and attributes as RDF classes, and also determines the structure and semantics of a CC/PP profile. The actual vocabulary defining which features of devices can be described is left open. An OMA extension of the CC/PP model with a standard vocabulary, the User Agent Profile (UAProf) [13], defines exactly how the capabilities of devices are named and what values are allowed. There have been attempts to define methods for using CC/PP profiles with SIP, but no standards have evolved from them. G. IMS GRUU Over the recent years, 3GPP developed the IP Multimedia Subsystem (IMS) as an all-IP NGN service infrastructure. A user can register multiple devices towards the IMS and always be reachable through a single public address. Communication is established using a simple forking mechanism, whereby all registered devices are addressed simultaneously. From release 6 on, the IMS supports the Globally Routable User Agent URI (GRUU) [14], which allows to identify and address individual user devices, bypassing the forking. However, the system still lacks an intelligent entity which collects and analyzes information about the subscriber, his devices’ capabilities and his preferences in order to personalize the service delivery accordingly and e.g. choose the best device for establishing a particular session. IV. P ERSONALIZED C OMMUNICATION O PTIMIZATION Aiming for an optimization of real-time communication in multi-device and multi-session scenarios, we have proposed [6] a Personalized Communication Controller (PCC), which allows for service invocation and session modification

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

TABLE I U SER PREFERENCES FOR THE PCC ( ABBREVIATED ) Preference ringing loudness presence info sessions while roaming call acceptance accepted session types message delivery voice mail message storage sync. address book sync.

Domain loud / normal / quiet only to listed contacts / to all / hidden no / yes (for video / audio / text) all / only urgent / only private / none / only from listed contacts video, video-only-with-wlan, audio, text discard (with optional notification) / defer / store in network (for video, audio, or text, respectively) when offline, when busy, when not answered everything / just-headers; device list device list

control based on dynamic information about all communication activities of the user. It is placed in the IMS signaling and media paths across all active sessions of one user and carries also functionalities attributed to the 3GPP-proposed Service Capability Interaction Manager (SCIM) [14], which has never been specified in detail. The PCC is controlled by a policy engine which makes decisions about how to handle communication events based on flexible user- and/or operatordefined policies. The PCC’s abilities for communication personalization are substantially enhanced by the inclusion of user preferences and device capabilities into the policy framework, because this allows to make real-time decisions based on them. The following sections describe the PCC components which enable this enhanced personalization, the User Preferences Profile Manager and the Device Capabilities Profile Manager, as well as their relation to the respective standard mechanisms described in section III. A. User Preferences Profile Manager The User Preferences Profile (UPP) Manager is the PCC component which retrieves and stores the preferences of the user relating to real-time communication or other types of conversations. For preference management, we use the User Preference Profile concept from the upcoming CPM standardization (cf. section III-B), where preferences are organized into profiles, and profiles are stored on an XML Document Management (XDM) server. On the basis of the CPM requirements, we defined a set of preferences that will probably be a subset of the CPM preferences (cf. Section III-C) when these are eventually standardized. This subset is displayed in Table I. In order to allow storage with the XDM enabler, we also defined the respective Application Usage, including an XML schema for preference profiles. Fig. 3 shows how User Preferences Profiles are accessed and used in our PCC approach: The user manages his profiles on the XDM server directly via the XCAP protocol using his terminal, or via a web-based frontend. When the user registers a device with the IMS, the PCC downloads the active profile for this device using XCAP and applies the contained preference settings for communication personalization. The

PCC additionally subscribes to the active profile with the XDM using the SIP event notification mechanism, so it is notified if the user changes preferences while registered. In this case, the UPP manager updates his copy of the respective profile and triggers reconsideration of the current communication activity state according to the new preferences. B. Device Capabilities Profile Manager Besides user preferences, device capabilities must be taken into consideration in order to bring a personalized experience to the user. The Device Capabilities Profile Manager is the PCC component responsible for managing the user’s pool of devices and keeping track of all devices’ capabilities. A separate device capability profile is maintained for each device inside an internal device capability database; the GRUU (cf. section III-G) is used as the key for identifying them. In our approach, we use the CC/PP-based UAProf standard (cf. section III-F) for representing device capabilities. We treat device capabilities as resources, and each device has its own resource profile. The standard UAProf resource profile vocabulary defines six categories of device capabilities: hardware, software platform, browser user agent, network characteristics, WAP characteristics and push characteristics. We divide device capabilities into two main groups: static and dynamic capabilities. Static capabilities are the capabilities inherent to each device and therefore unchangeable (e.g. whether the device supports stereo audio). Dynamic capabilities can change during the life time of the device (e.g. battery resources, installed codecs, or other software). We extended the UAProf vocabulary to allow the PCC to recognize if a user’s device is currently streaming audio or video, independent of whether that is part of a real-time communication session or not. The following dynamic hardware capabilities were added for this: VideoInputInUse, VideoOutputInUse, SoundInputInUse, and SoundOutputInUse [15]. The Device Capabilities Profile Manager parses, validates and stores all device capability descriptions for a user’s devices. C. Exchange of Device Capabilities over the IMS network Although the UAProf standard addresses how device capabilities can be described, it does not address how these capabilities are to be communicated to the server or how the device capability information is to be used by the server.

Fig. 3.

User Preferences Profile management in the PCC

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

PUBLISH sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.103:5060;branch=z9hG... Max-Forwards: 70 Privacy: none From: ;tag=9bad49cd08... To: Call-ID: 5374d3f4950878b01948637cacb54203@HTC-P3600 CSeq: PUBLISH CapSeg: 9 Event:devCap Expires: 7200 Route: Content-Type: application/pidf+xml Content-Length: 1500 NEC Xyz-123 LanAccess 640x480 ...

Fig. 4.

RDF document embedded in a SIP PUBLISH message

The proposed way of indicating User Agent Capabilities in the SIP protocol [16] allows to pass information about device capabilities during the registration in the SIP contact header field. This, however, is not part of the IMS specification, i.e. the IMS control layer is not prepared to read and use the capability information. Besides, inserting a lot of tags for detailed capability descriptions in the contact header does not seem to be a very good approach as well; the mechanism was rather designed for simple and short feature lists. In our solution, we use the IMS infrastructure and the SIP protocol for transmitting static and dynamic device capabilities using SIP PUBLISH messages. When a device registers itself towards the IMS, it also sends a PUBLISH message, the body of which contains the RDF XML describing its capabilities. This way, the PCC immediately gets the necessary device capability information. An excerpt of such a SIP PUBLISH message is given in Fig. 4. After having published all capabilities initially to the PCC server, the device updates the PCC about its dynamic capabilities on demand, also using SIP PUBLISH messages. These SIP messages contain only the capabilities which have changed. This keeps the network usage overhead for the transmission of device capability information to a minimum. Alternatively, the PCC also supports devices that do not publish their capabilities over SIP. In this case, devices have to be entered into an internal database (this can be thought of as an extension of the subscriber information) with their GRUU and a URI where the Device Capability Profile Manager can download their UAProf description upon registration, e.g. from a web server. D. Evaluation of User Preferences and Device Capabilities The policies used by the PCC’s policy engine for making real-time decisions are expressed in XACML, the XML-based

[email protected] ... ...

Fig. 5.

Example User Preferences document

eXtensible Access Control Markup Language [17]. This language has a resource concept which is similar to the RDF one. In our XACML policies, device capabilities can be referenced through attributes assigned to resources. User preferences are made accessible by policies in a similar way. The device capability and user preference information is analyzed at run-time during evaluation of the XACML policies in order to personalize the service delivery. E.g., it is easily possible to always chose the most fitting device for certain types of real-time services or communication. The details of this mechanism are described in a separate paper (pending publication). V. E XAMPLE S CENARIO As an example of how to apply the device capabilities and user preferences profile management to optimize real-time communication in a multi-device environment, we look at the following scenario: Alice is a user having two devices that differ in their capabilities – one device is capable of receiving audio and video, the other only audio. In the beginning, Alice is enjoying an audio/video streaming session on her first device. Now Claire, a friend of Alice, tries to call her. The call is automatically rejected (and not signalled to any of Alice’s devices) because Alice has selected a profile that only allows particular contacts to call her, and Claire is not among these. However, the PCC sends a text message to Alice, informing her about Claire’s call. Later on, Alice receives an audio/video call from Bob, who is an important business partner of Alice. Bob is among the allowed callers, but the profile further prescribes to only receive audio parts, so the video is left off. Based on the additional information that Alice’s first device is busy with audio and video, the PCC decides to forward only the audio part of the call to her second device. At the same time, the audio part of Alice’s video streaming session is muted automatically by the PCC, so she is not disturbed by the noise during her important call. Fig. 5 shows an excerpt from a User Preferences Profile that is applicable for such a scenario. VI. I MPLEMENTATION We chose the Mobicents implementation of the JAIN Service Logic Execution Environment (JSLEE) [18] as our execution environment and the Fokus Open IMS playground [19] as

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2009 proceedings.

our IMS platform for building a prototype implementation. We decided for JSLEE because it already provides a middleware suitable for developing software in the telecommunications networks domain, especially for handling SIP signaling over the IMS. Moreover, it provides a powerful framework for handling different types of asynchronous messages. The JSLEE framework provides a component model where cooperating components can build sophisticated communication services. The components are called Service Building Blocks (SBB). Instances of SBBs, called SBB entities, have persistent state, even though they are mapped to real objects (coming from a pool) only temporary, i.e. when they are executing and e.g. handling SIP messages. In our implementation, the PCC is built of several SBBs; the User Preferences Profile Manager e.g. is one of them. Each IMS subscriber has an individual instance of the PCC while he is registered with the IMS, and the SBB entities of that instance manage all information about that user’s sessions, devices and preferences. All database functionality of the Device Capabilities and the User Preferences Profile Manager modules has been implemented using the Enterprise Java Beans (EJB) technology, which ensures a certain availability and scalability. VII. S UMMARY AND C ONCLUSION In this paper, we presented the handling of user preferences and device capabilities in our Personalized Communication Control component, a network-based system for personalization of telecommunication service delivery. Being placed in the IMS signalling and media paths, the PCC has information about all communication activities of the user and can influence them for personalization. User preferences and device capabilities are used by the policy engine that controls the PCC’s actions. We defined an XML schema for User Preference Profile documents to be stored on an XDM server, covering a couple of exemplary user preference settings that are useful in the personalization scenarios we are currently considering. The PCC downloads the active profiles for registered devices and keeps the copies up-to-date using the SIP event notification mechanism. A similar approach is likely to be standardized for the upcoming CPM enabler by OMA. For the description of device capabilities, we started with the established UAProf specification and extended it to cover the dynamic availability of some resources. This allows the PCC to react differently when resources are unavailable, even if they are allocated via mechanisms that are otherwise beyond its awareness and control. We defined a SIP extension for communicating device capabilities from user devices to the PCC during the registration process. Dynamic changes can be sent to the PCC in any case. By dinstinguishing between static and dynamic capabilities and transferring only what is not already known to the server, the process has low bandwidth requirements. By applying the personalization in the core network, the device multiplicity and the combined set of device capabilities availalable to the user is transparent to applications and other

users. Changes in preferences or device capabilities can immediately affect running sessions, without having to renegotiate with other parties involved in them. Session modifications can stretch over multiple devices, e.g. by transferring part of the media of a session to another device. Personalization works in the same way across different services as well as access networks (fixed or mobile), thereby simplifying and improving the user experience. ACKNOWLEDGMENTS The authors would like to thank Moise Ndala and Mauro Sardinha for their contributions during their internships at NEC Laboratories Europe. R EFERENCES [1] M. Bonett, “Personalization of web services: Opportunities and challenges,” Ariadne, no. 28, Jun. 2001, ISSN 1361-3200. [Online]. Available: http://www.ariadne.ac.uk/issue28/personalization/intro.html [2] “Subscriber data management: It’s time to get personal,” Light Reading, Tech. Rep. Vol.4, No.1, Feb. 2008. [3] Foresight 2020: Economic, industry and corporate trends, Economist Intelligence Unit, Mar. 2006. [Online]. Available: http://www.eiu.com/site info.asp?info name=eiu Cisco Foresight 2020 [4] N. Imai, N.Isomura, A.Idoues, H.Horiuchi, T.Ubukata, Y.Chiba, and S.Uno, “Dynamic session modification between multiple devices in the IMS/MDD architecture,” IEEE WCNC, pp. 3255–3260, Mar. 2008. [5] R.Shacham, H.Schulzrinne, S.Thakolsri, and W.Kellerer, “Ubiquitous device personalization and use: The next generation of IP multimedia communications,” ACM Transactions on Multimedia Computing, Communication and Applications, Vol.3, No.2, Mar. 2007. [6] A. Sch¨ulke, D. Kraft, J. Bauknecht, A. Hassan, M. Kuhnen, and M. Lischka, “Real-time SDP personalization in a multi-device environment,” in Proceedings of World Telecommunication Congress (WTC). IEEE, 2008, to be published. [7] Converged IP Messaging Requirements, Draft Version 1.0, Open Mobile Alliance, Apr. 2008, OMA-RD-CPM-V1 0-20080422. [8] J. Rosenberg, The Extensible Markup Language (XML) Configuration Access protocol (XCAP), IETF, May 2007, RFC 4825. [9] XML Document Management (XDM) Specification, Candidate Version 2.0, Open Mobile Alliance, Jul. 2007, OMA-TS-XDM Core-V2 020070724-C. [10] A. Roach, Session Initiation Protocol (SIP)-Specific Event Notification, IETF, Jun. 2002, RFC 3265. [11] J. Urpalainen, An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package, IETF, May 2008, work in progress. [Online]. Available: https://datatracker.ietf.org/drafts/draft-ietf-sip-xcapevent/ [12] Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0, W3C Consortium, Jan. 2004. [Online]. Available: http://www.w3.org/TR/CCPP-struct-vocab/ [13] User Agent Profile, Open Mobile Alliance, Feb. 2006, OMA-TSUAProf-V2 0-20060206-A. [14] 3GPP Technical Specification Group Services and System Aspects: IP Multimedia Subsystem (IMS), Stage 2 (Release 6), 3rd Generation Partnership Project, Mar. 2007, TS 23.228 V6.16.0. [15] M. Ndala, “An intelligent service delivery control unit for multi-device communication services in IMS,” Master’s thesis, Ecole Polytechnique Federale de Lausanne, Oct. 2007. [16] J.Rosenberg, H.Schulzrinne, and P.Kyzivat, Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), IETF, Aug. 2004, RFC 3840. [17] eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS, Feb. 2005. [18] “Mobicents.” [Online]. Available: http://www.mobicents.org/index.html [19] “FOKUS OpenIMS playground.” [Online]. Available: http://www.openimscore.org/