Virtual Community Management for Enabling P2P Services in the IMS Network

Transcription

1 Virtual Community Management for Enabling P2P Services in the IMS Network Igor Radovanović, Johan Lukkien, Shudong Chen, Chris Molanus, Tanır Özçelebi Department of Mathematics and Computer Science, Eindhoven University of Technology Eindhoven, the Netherlands i radovanovic@yahoo.com, j.j.lukkien@tue.nl, shudong.chen@tue.nl, c.a.molanus@student.tue.nl, t.ozcelebi@tue.nl Abstract This paper addresses forming and management of a virtual community (VC) in the IP Multimedia Subsystem (IMS) network. A VC provides scope for mobile peer-to-peer (P2P) service sharing among end users and allows them control of sharing. The paper describes a number of services that enable forming and management of virtual communities and presents several service-oriented system architecture alternatives focusing on distribution of service access control and service discovery control between end users and operators as the owners of the IMS home-networks. Presented architecture alternatives are IMS compatible since they only introduce 5 additional services into the existing IMS architecture. A key service is an orchestrator that exposes new services composed of other services. A proofof-concept realization of the IMS architecture in which control of mobile service sharing is distributed among end users and operators is shown. I. INTRODUCTION The Internet has always been developing towards an open environment with high flexibility and distributed control and management, where complexity is put in end devices rather than in networks. This has not only enabled development of a myriad of applications by end users, but also enables the introduction of overlay networks on top of existing network infrastructures, in which devices belonging to the end users are used to route messages to other end devices, further shifting control from networks to end devices. Those overlay networks are used mainly for P2P content and storage sharing [1] which can be extended to P2P services sharing in general. The downside of the complexity being placed in end devices is that the end users, owning those devices, have to carry the burden of system and service management and security. The main mechanisms required for that are service discovery control and service access control. The former is used to discover services and the latter is used to permit, prioritize, and schedule the access to services [2]. Internet-based services offered by end users, content and application providers have become less dependent on network transport service, as quality of provided services increased over the last years, mainly due to overprovisioning of network resources. This trend leaves network providers (e.g. telecom operators) with little contribution to the value chain as application and content providers use networks as bit pipes for their services to the end users. A threat that network providers face is that they slowly lose their central role in the networked systems as the enablers of the end-to-end communication. Operators can try to avoid this by providing novel network services (services delivered by the network), which in combination with other networked services (user services accessible via a network) create new personalized applications. These services have to facilitate reliable and secure sharing of userowned mobile P2P services, and allow end users to have control of this sharing. Currently, the main advantages of services provided by telecom operators to users are guaranteed quality of service and improved trust offered to end users. An additional advantage is simplicity of usage, as complexity (of managing infrastructure and services) stays in the network rather than being shifted to end devices. Quality, trust and simplicity are results of system and service management, enabled by control of the system. The introduction of IP Multimedia Subsystem (IMS) proves the development of operators networks in this direction. IMS [3] is a backward compatible NGN architecture designed and standardized by the 3rd Generation Partnership Project (3GPP) group [4] for enabling a large variety of Internetlike services with easy provisioning for telecom operators. IMS aims to integrate legacy networks with the IP-based networks and provide services (applications) to end users at anyplace, anytime. The Session Initiation Protocol (SIP) [5] is employed at the application layer as a control safeguard in order to simplify integrating IMS with the Internet. The original intent of the IMS designers was to make the system architecture service oriented; however no explicit support for service publishing and discovery has been provided. In addition, the architecture fails to provide end users with a possibility to share their services over the network, just like they can do that over the Internet [8]. There are also drawbacks regarding the SIP protocol, which does not inherently provide separation of mobile services and devices on which services are running [8]. To make the desired system, operators need to distribute system complexity among end devices and network, giving access control to services owned by the end users partially back to these end users [6], [7]. The end users may also be given some control of service discovery. This can be possible if the system architecture is made flexible enough and discovery and access to services is secure. Flexibility can be solved by introducing service orientation into the IMS [8], whereas secure sharing can be achieved by introducing the virtual community concept [9]. This paper addresses the latter focusing on virtual community forming and management using standard protocols. Included are secure service discovery,

2 access and orchestration as well as distribution of service discovery control and service access control between end users and operators. The latter is addressed in the analysis of several service oriented architectural alternatives. II. RELATED WORK Sharing mobile peer-to-peer (P2P) services in IMS networks has been reported in the literature [2], [6]-[8]. In [7], authors present additions to the existing IMS architecture to provide mobile P2P services. They introduce a single additional service (a SIP-based application) for assigning super-peer roles in the system. They also present additional services for management, authentication, authorization and accounting, charging and digital rights management. Although the presented design uses an opensource security package, no detailed description of secure service discovery and access has been reported. Moreover, the paper does not address explicitly the issues of service discovery control and service access control and their possible distribution between end users and operators. The paper [6] presents a mobile client software architecture that allows mobile P2P content sharing in IMS networks. In contrast to server based architectures for content sharing [7], this solution uses the SIP protocol as a basis for deployment of mobile P2P services and adopts an architecture based on super-peers. The authors describe functionality of software components for content discovery control (i.e. publishing and searching) as well as the content transfer. They also address content access control of end users in the system. But security issues and the distribution of content mediation control and content access control are left unaddressed. The burden of managing the overlay infrastructure is left to the end user. Introducing P2P services into IMS is also shown in [8]. The paper presents an addition to the existing client software architecture in the IMS system by combining Web Services with SIP, to enable end users to become service providers and to facilitate P2P sharing in IMS. However, the paper addresses neither virtual community management, nor security aspects related to mobile service sharing. As result of a clientbased solution, the overlay infrastructure management has to be solved by the end users. In [10] the authors present a network based addition to the existing IMS architecture in the form of Index nodes forming a Chord-like ring overlay network [11] to realize the DHTbased distribution. They also describe SIP control signalling for file mediation and access control, while a description of VC forming and maintenance, and distribution of service discovery and access control is missing. Resource control and mediation in a mobile system combining fundamental P2P concepts with the mobile networks, are given in [2]. The paper gives a classification mechanism for mobile P2P architectures based on coordination and control of resources. This classification is used in our proposed solution as well for assessing different system architectural alternatives, taking services rather than resources into account. While [2] presents a single architecture that gives resource access control to end users, and resource discovery control to the operators, it does not address VC forming and maintenance. III. SYSTEM ARCHITECTURE To make a mobile IMS network where users can share P2P services, two functions are needed: service discovery control and service access control. Service discovery control includes service advertisement and is required for users to expose and find services. Service access control limits the discovery scope and is required so that users can manage and control the extent of sharing. In our design we combine these two functions in the concept of a virtual community (VC) as in [9]. In addition, we build the entire system as a Service Oriented Architecture where a community is made up of discoverable VC services. An outline of our VC operation is as follows. A user (or a service representing the user) knows an access point to the community where she presents her credentials. Through the access procedure, the user obtains a certificate for the VC. The certificate is needed in later interactions within the community and it represents a VC-level access control. Any authenticated VC member can expose services to the community. These services can only be found and accessed through a valid certificate. The service owner can provide further service-level access control (i.e. in addition to certificate access control) by enforcing an access policy. The registration and discovery of (user) services is done through a repository service, which leads to less overhead than broadcasting a query. In addition it relieves the user side from maintaining a view on the available services and it provides better protection of privacy since queries only reach the repository. Once services are discovered they can be orchestrated into an application. An orchestrator is a special service that is capable of using discovered services. In its basic form this means connecting service interfaces (i.e., connecting a provided interface of one service to a required interface of another one). A more elaborate orchestrator may add some logic, effectively acting as a service consumer and may expose a new service composed from other services. Building an orchestrator can be entirely the responsibility of the user. Alternatively, the community may provide an orchestrator service which takes a description of the orchestration as input and subsequently realizes the orchestration. This allows for sharing standard functionality that each orchestrator needs and supports further standardization of service interfaces. Finally, a VC supports quality of service monitoring. A user will experience a certain quality of a service she is using. This quality is monitored and recorded by a special service whose result can further be used for selecting a service. User behavior related to VC policies is also monitored, so that a users reputation is maintained. In summary, a VC is defined by the following core community services. The entry point is formed by the VCEntry service that returns access points for the other VC services, as well as a certificate. This certificate is obtained from the CertificateMgt service. The certificate certifies that the user

3 is indeed a member of the community as well as her access rights. The certificate can be decoded using the public key of CertificateMgt. Registered members can register and query the Repository service. An Orchestrator service supports setting up orchestrations as the means to use services. Behavior within the community and delivered service quality is monitored by the CreditMgt service. Although we describe these services as just single instances, replication is possible for scalability and reliability. Internal consistency protocols must then be in place. However, these are standard solutions and beyond the scope of this paper. A service-oriented architecture brings the problem that ownership of a device that runs a service does not imply control right of the usage of that service, since access to a service is via the network. For reliable operation, service registration should therefore come with a contract or resource budget that the service is sure to have on its platform. VC services can partly or entirely be deployed as either networked or network services. This leads to service access and discovery being either in the operator domain or in the user domain. We will analyse the two extreme cases and the hybrid case below, followed by our decision. In this comparison we use the following criteria: i) confidentiality and integrity of service discovery control, ii) service access control, iii) reliability of the system, iv) trust in users and operators, v) costs for end users and operators, and vi) scalability of the architecture in terms of response time. A. Deployment as user services In this deployment scenario all VC services are deployed on user devices (e.g. PCs, mobile phones, handhelds or Consumer Electronics equipment). This scenario gives the end user full control of how service discovery, access control and orchestration are implemented, and consequently full control of service discovery and service access. Little trust in the operator is needed since all communication between the services can be done over a secure channel, e.g. SSL. A major concern is the intermittent connectivity of a user s device and the possibility of the device being taken off-line without prior notice. If this device were providing a service, it would put the burden of overcoming such an event on the other end user devices in the VC, e.g., by replacing a core service with a substitute. These events also have implications for the overall reliability of the system. In addition, the end devices are typically resource constrained which may lead to slower service response as the VC size increases. Another concern is the total amount of transferred data. In IMS, all signaling traffic will go through the Call Session Control Function (CSCF) servers to reach the VC core community services, e.g., a service registration will involve VCEntry, Repository and CertificateMgt. If VC core services are distributed among end devices, VC core signaling among them is required, which will lead to more signalling traffic compared to the scenario where the services are co-located centrally. The operator would have little of service access and service discovery. The network would simply be used as a bit-pipe with the increased traffic as sole benefit. An operator would not be considered a stakeholder in the widespread adoption of this architecture. Little standardization and cross-community re-use of services can be expected. B. Deployment as network services The other extreme is to deploy all core community services on the application server of the IMS network. As opposed to the dynamism of a mobile end device, the presence of the application servers and the core community services in the IMS network is much more stable. Hence, service discovery and system maintenance become less of an issue. From the user s perspective, the functionality to implement VC properties would have to be provided by the operators, and consequently the user would have little or no control of service access and service discovery. There is however little need for end users to carry the burden of system maintenance which therefore, increases the reliability of the system. Since the application servers typically have more resource available to them and a certralized solution requires less VC core signaling, such a system is more scalable in terms of response time. This scenario uses less of the network s bandwidth and therefore generates less charges for users. From the operator s perspective, by having control of all core community services, they can choose how to implement the IMS framework to meet their own financial objective on the one hand, and their costumers expectations on the other. Control of all core community services gives an operator full control of service discovery and service access. With this, operators can better estimate the return on investment of these services, so that they can make an informed adjustment to their business model. A particular point here is the position of the orchestrator. If it is deployed as a user service, it mainly serves as a means to construct applications. When used as a network service it becomes easier for the operators to use the orchestration information in resource allocation and control, since such allocation is under full control of the operators. Although this works fine for the simple orchestrations that just connect services, it becomes more problematic to implement when orchestration contains logic and even exposes services. This has to be managed by enforcing service agreements between users and operators. C. Hybrid deployment In this scenario, some core community services are hosted by the operator and the others by the end users, depending on the comparison criteria metioned above. A balance would have to be found between the users ability to control the service access and service discovery and the benefits of having the service hosted by the operator. Generic (parameterized) services which end users can inherit can be used to tailor core community services according to the requirements of the user. An orchestrator is a good example of this: it takes

4 Fig. 1. The chosen hybrid deployment scenario of the core community services. Control of the VC is distributed over all three domains. an orchestration description as a parameter to perform the requested setup as explained above. Another alternative is that the VCEntry service is deployed as an IMS service. The operator guarantees to keep this gateway service running steadily. Meanwhile, an end user is allowed to choose his own VC maintenance policy. A possible way to do this is to make the VCEntry service capable of processing commands uploaded by users. In this way, the burden of the service discovery, as well as maintenance of the overlay, could be shifted to the operator, while the users could remain in control of the service discovery and the service access. The extent of this control would depend on which core community services are deployed in the operator s domain as well as how thes are implemented. In hybrid deployment, a high level trust from operators to end users is required since the operators would be allowing user-code to run inside their networks, which would therefore increase the complexity of service implementation. This trust can be mitigated by making legally binding agreements between the end user and the operator, and additional access control to core community services is mandatory. Allowing end users to host various services on their own devices would provide them with the highest extent of access and discovery control of these particular services. This comes along with increased data traffic to end devices boosting service costs. With the above analysis of the three different deployments, the hybrid deployment to form VCs in the IMS network is adopted in this paper. This deployment, depicted in Fig.1, gives end users more flexibility in how they choose to implement VCs, they have to loosely trust the operators, and they are relieved of maintenance problem. The VCEntry is actually implemented on a user device while other core community services including the CertificateMgt and the Repository, are deployed in the operator s domain. Other services registered by members will be hosted on end devices. Due to the trust relationship and the reputation consideration, the CreditMgt is under the control of the operators. Operators can provide their clients with added value by offering this CreditMgt service, which can also be used for accounting purposes. Fig. 2. Virtual community forming. IV. VIRTUAL COMMUNITY MANAGEMENT If an end user wants to share files with her friends over IMS, e.g., pictures and videos, she can firstly create a VC; then invite her friends to join this VC; next register services which can provide this file sharing functionality; and finally set up a file sharing application through combining these registered services. Service use (application creation) in a VC is done by an orchestrator which first discovers the required services from the repository, and then binds them together taking care of the service interfaces and protocols for connection and communication. A. Virtual community forming The VC formation process will be started once an initiative arises, e.g., file sharing among a group of trusted end users. The process of establishing a new virtual community is shown in Fig.2. In order to grant a creator control of service access and service discovery, VCEntry, which facilities the member registration and service publication, will run in the end user s domain as a user service. Hence, the creator has the right to define the join policy to the VC. After the VC is formed, the creator can broadcast the existence of this new VC to the network or multicast to her friends. Some of the core community services, including CertificateMgt, Repository, and CreditMgt will be deployed in the operator s domain as core IMS services for the sake of the costof system maintenance and of discovery. The CertificateMgt service generates a signature for this VC which will be later used for member and service authentication. Repository acts as an intermediary between service providers and service seekers. Authorized VC members can discover registered services from this repository or register their own services for sharing. To deploy CertificateMgt, the creator asks a deployer running on the application server to create or find an existing one and return the address. The same is true for the deployment of Repository. The access points of

5 Fig. 4. VC service registration. Fig. 3. VC member registration. CertificateMgt and Repository will be advertised to VCEntry. The shared secret of this VC, (e.g. the public key for authenticating CertificateMgt s signature), will be advertised among these core community services. In our implementation, all communication is done in SOAP, and all binary objects are first encoded into base64 so that they can be placed in the SOAP message. B. Virtual community member registration One of the main goals of forming a service-oriented VC in IMS is to keep the privacy of service providers and to secure the interactions among services. Therefore, service discovery and access can only be done within the scope of a VC. An end user first needs to register as a member and only then she can see the presence of other registered services. To become a VC member, an end user (represented by a device) needs to provide her profile to VCEntry and then the member registration process is activated. As shown in Fig.3, an applicant s profile is checked by VCEntry with the JoinPolicy to decide whether this user can be approved or not. If she is approved, VCEntry will invoke CertificateMgt to register her as a member of this VC. Upon the success of above steps, VCEntry will inform this new member about the access points of both the Repository and the CertificateMgt, together with the shared secret of this VC. With the access point of CertificateMgt, the member can apply for tickets which is required for each activity happening in this VC. C. Virtual community service registration and use A VC member can now discover registered services using the Repository. To register a new service, a member can send her service registration request to the Repository which will first check the validity of this member s ticket and dependin on the outcome, register this service. Compared to a service running outside a VC, a registered VC service is enriched with additional properties, like a black list and an access control list for making a local access control policy. Available roles of members and corresponding actions are stored in the access control list. Malicious user s information can be inserted into the black list. As stated previously, the operators can provide the end users with added value if some core Fig. 5. Secure service access. community services are deployed as network services. As an example, as part of the service registration this newly registered service will be assigned a credit value, for instance threshold +1 in Fig.4, by CreditMgt. This credit value will either increase or decrease based on the behavior of a service. In this way,the behavior of a service and its provider can be monitored. This is advantageous for both users and operators, as users can obtain better quality while operators can remove badly performing services. As a result, the trust between the operator and the end users can be increased. Within the scope of a VC, end users can build applications through composing the registered services by the orchestrator. This orchestrator discovers required services from the repository and binds them at runtime to create applications. During the execution of an application, SOAP messages exchanged between services will be encrypted to be carried by SIP, as shown in Fig.5. V. EXPERIMENTAL PLATFORM In order to test the feasibility of this service-oriented VC overlay in IMS, a file sharing example scenario is designed. In this scenario, an end user wants to share a picture stored on her mobile phone with her two friends. Considering the privacy of the content, she first creates a VC and then invites her friends to join. She registers a file server service into the Repository of this VC. And her two friends, who are VC members, now publish their file sink services and mouse services into the Repository. She uses an orchestrator to bind the file server service with one of the file sink services and meanwhile subscribes the orchestrator to the two mouse services for their double click mouse events. After the application starts, the picture will be transmitted from her mobile phone to one of her friends mobile phone. The picture destination can be switched to her other friend through a double click mouse event generated by another mobile phone. In this scenario, we deployed the VC core services and registered services in the

6 in existing SSL implementations. One of the key differences would be that SIP would be used as the transport protocol, particularly the SIP Message method. Fig. 6. Service deployment of the file sharing scenario. VCEntry is not connected to other services because the member- and the service registration are not shown. CreditMgt will be connected after the files have been shared. Fig. 7. A screen flash of the file sharing scenario. VI. C ONCLUSIONS This paper introduces 5 services enabling mobile P2P service sharing in the IMS network. It presents an analysis of three system architecture alternatives for forming and managing virtual communities. For each of the alternatives, distribution of service discovery control and service access control among end users and operators is discussed, and pros and cons from both the user s and the operator s perspective are given. In addition, a proof-of-concept of a mobile P2P file sharing service is demonstrated. The main contribution of the paper is the introduction of the VC concept and an orchestrator service in IMS. The main benefit for the user is the ability to control service sharing, while the main benefit for the operator is the possibility to generate more revenue. The operators are in control of critical services and the system maintenance. Our future work will focus more on the security of the complete system, as an extension to security of service access and service discovery provided here. ACKNOWLEDGMENT This work is supported by the COMET consortium funded by the European Commission 6th Framework Programme. R EFERENCES Fig. 8. Layered architecture of the experimental platform. manner depicted in Fig.6. Fig.7 shows a physical deployment and a screen flash of the file sharing scenario. Fig.8 illustrates the proof of concept of our solution. The example scenario was created using the standard-based IMS network simulator with communication services emulators. The open Source Glassfish/SailFin JavaEE/SIP server was used as the network application server [12]. UIQ 3 SDK emulators [13] where used as end devices which use the Ericsson s IMS Client Platfor (ICP) for Open-OS devices that extends JSR 281 standard [14]. The VC is created by an administrator (Admin) to allow end users to become members through an entry point. The same program also allows a file server (service provider) to share files with other users (service requesters) after joining the VC. The application is in principal split into two parts. The mobile application can take on the roles of, an Admin/ VCEntry, a service provider, or a service requester. The server application, which represents the network services, can function as a deployer, CertificateMgt, or a Repository. The deployer allows the Admin to create an instance of the CertificateMgt or the Repository. After creating the instance, it replies with the SIP address of the newly created instance. Secure channels are created similar to how they are created [1] P. Triantafillou and C. Xiruhaki and M. Koubarakis and N. Ntarmos, Towards High Performance Peer-to-Peer Content and Resource Sharing Systems, Proc. of CIDR, [2] F-U. Andersen et al., An Architecture Concept for Mobile P2P File Sharing Services, in Lecture Notes on Informatics (LNI) P-51, pp , ISBN , [3] Digital Cellular Telecommunications System (Phase 2+), Universal Mobile Telecommunications System (UMTS), IP Multimedia Subsystem (IMS), Stage 2, V7.6.0, TS , 3GPP, Dec [4] Oct [5] J. Rosenberg, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler SIP: Session Initiation Protocol,, RFC 3261, IETF Network Working Group, June [6] M. Matuszewski, N. Beijar, J. Lehtinen, T. Hyyrylainen, Mobile peerto-peer content sharing application, in 3rd IEEE Consumer Communications and Networking Conference (CCNC), [7] A. Liotta, L. Lin, The Operator s Response to P2P Service Demand, in IEEE Communications Magazine, pp , July [8] Igor Radovanovic, Amit Ray, Johan Lukkien, Michel Chaudron, Dynamic mobile service provisioning in IP Multimedia Subsystem (IMS) using a Service Oriented Architecture, in the Springer Verlag as a part of its Lecture Notes in Computer Science series (LNCS 4749), [9] Shudong Chen, Igor Radovanovic, Johan Lukkien, VICSDA: Using Virtual Communities to Secure Service Discovery and Access, in the Springer Verlag as a part of its Lecture Notes in Computer Science series (LNCS 4577), [10] X. Ye, J. Zhang, J. Wang, Architecture of HIKEC: An IMS-based Mobile P2P File Sharing Service, in Proc. of International Conference on Communication Technology 2006, ICCT 06, pp. 1 4, Nov [11] I. Stoica et al., Chord: A scalable peer-to-peer lookup service for internet applications, in Proc. of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM 01), Vol. 31, No. 4, pp , Oct [12] Oct [13] Oct [14] Sun Microsystems, JSR 281 IP Multimedia Subsystem (IMS) Services API, Public Draft version 0.9, Sep