Virtual Community Management for EnablingP2P Services in the IMS Network

Igor Radovanovic, Johan Lukkien, Shudong Chen, Chris Molanus, Tanır OzcelebiDepartment of Mathematics and Computer Science, Eindhoven University of Technology

Eindhoven, the Netherlandsi 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 avirtual 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 ofsharing. The paper describes a number of services that enableforming and management of virtual communities and presentsseveral service-oriented system architecture alternatives focusingon distribution of service access control and service discoverycontrol between end users and operators as the owners of theIMS home-networks. Presented architecture alternatives are IMScompatible since they only introduce 5 additional services intothe existing IMS architecture. A key service is an orchestratorthat exposes new services composed of other services. A proof-of-concept realization of the IMS architecture in which controlof mobile service sharing is distributed among end users andoperators is shown.

I. INTRODUCTION

The Internet has always been developing towards an openenvironment with high flexibility and distributed control andmanagement, where complexity is put in end devices ratherthan in networks. This has not only enabled development ofa myriad of applications by end users, but also enables theintroduction of overlay networks on top of existing networkinfrastructures, in which devices belonging to the end users areused to route messages to other end devices, further shiftingcontrol from networks to end devices. Those overlay networksare used mainly for P2P content and storage sharing [1] whichcan be extended to P2P services sharing in general. Thedownside of the complexity being placed in end devices is thatthe end users, owning those devices, have to carry the burdenof system and service management and security. The mainmechanisms required for that are service discovery control andservice access control. The former is used to discover servicesand the latter is used to permit, prioritize, and schedule theaccess to services [2].

Internet-based services offered by end users, content andapplication providers have become less dependent on networktransport service, as quality of provided services increasedover the last years, mainly due to overprovisioning of networkresources. This trend leaves network providers (e.g. telecomoperators) with little contribution to the value chain as ap-plication and content providers use networks as bit pipes fortheir services to the end users. A threat that network providersface is that they slowly lose their central role in the networkedsystems 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 combi-nation with other networked services (user services accessiblevia a network) create new personalized applications. Theseservices have to facilitate reliable and secure sharing of user-owned mobile P2P services, and allow end users to havecontrol of this sharing. Currently, the main advantages ofservices provided by telecom operators to users are guaranteedquality 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 networkrather than being shifted to end devices. Quality, trust andsimplicity are results of system and service management,enabled by control of the system.

The introduction of IP Multimedia Subsystem (IMS) provesthe development of operators’ networks in this direction. IMS[3] is a backward compatible NGN architecture designedand standardized by the 3rd Generation Partnership Project(3GPP) group [4] for enabling a large variety of Internet-like services with easy provisioning for telecom operators.IMS aims to integrate legacy networks with the IP-basednetworks and provide services (applications) to end users atanyplace, anytime. The Session Initiation Protocol (SIP) [5]is employed at the application layer as a control safeguardin order to simplify integrating IMS with the Internet. Theoriginal intent of the IMS designers was to make the systemarchitecture service oriented; however no explicit supportfor service publishing and discovery has been provided. Inaddition, the architecture fails to provide end users with apossibility to share their services over the network, just likethey can do that over the Internet [8]. There are also drawbacksregarding the SIP protocol, which does not inherently provideseparation of mobile services and devices on which servicesare running [8].

To make the desired system, operators need to distributesystem complexity among end devices and network, givingaccess control to services owned by the end users partiallyback to these end users [6], [7]. The end users may alsobe given some control of service discovery. This can bepossible if the system architecture is made flexible enoughand discovery and access to services is secure. Flexibility canbe solved by introducing service orientation into the IMS [8],whereas secure sharing can be achieved by introducing thevirtual community concept [9]. This paper addresses the latterfocusing on virtual community forming and management usingstandard protocols. Included are secure service discovery,

access and orchestration as well as distribution of servicediscovery control and service access control between end usersand operators. The latter is addressed in the analysis of severalservice oriented architectural alternatives.

II. RELATED WORK

Sharing mobile peer-to-peer (P2P) services in IMS networkshas been reported in the literature [2], [6]-[8]. In [7], authorspresent additions to the existing IMS architecture to providemobile P2P services. They introduce a single additional service(a SIP-based application) for assigning super-peer roles in thesystem. They also present additional services for management,authentication, authorization and accounting, charging anddigital rights management. Although the presented designuses an opensource security package, no detailed descriptionof secure service discovery and access has been reported.Moreover, the paper does not address explicitly the issues ofservice discovery control and service access control and theirpossible distribution between end users and operators.

The paper [6] presents a mobile client software architecturethat allows mobile P2P content sharing in IMS networks. Incontrast to server based architectures for content sharing [7],this solution uses the SIP protocol as a basis for deploymentof mobile P2P services and adopts an architecture based onsuper-peers. The authors describe functionality of softwarecomponents for content discovery control (i.e. publishing andsearching) as well as the content transfer. They also addresscontent access control of end users in the system. But securityissues and the distribution of content mediation control andcontent access control are left unaddressed. The burden ofmanaging 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 softwarearchitecture in the IMS system by combining Web Serviceswith SIP, to enable end users to become service providersand to facilitate P2P sharing in IMS. However, the paperaddresses neither virtual community management, nor securityaspects related to mobile service sharing. As result of a client-based solution, the overlay infrastructure management has tobe solved by the end users.

In [10] the authors present a network based addition to theexisting IMS architecture in the form of Index nodes forminga Chord-like ring overlay network [11] to realize the DHT-based distribution. They also describe SIP control signallingfor file mediation and access control, while a description of VCforming and maintenance, and distribution of service discoveryand access control is missing.

Resource control and mediation in a mobile system combin-ing fundamental P2P concepts with the mobile networks, aregiven in [2]. The paper gives a classification mechanism formobile P2P architectures based on coordination and control ofresources. This classification is used in our proposed solutionas 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 P2Pservices, two functions are needed: service discovery controland service access control. Service discovery control includesservice advertisement and is required for users to expose andfind services. Service access control limits the discovery scopeand is required so that users can manage and control the extentof sharing. In our design we combine these two functions inthe concept of a virtual community (VC) as in [9]. In addition,we build the entire system as a Service Oriented Architecturewhere a community is made up of discoverable VC services.

An outline of our VC operation is as follows. A user (ora service representing the user) knows an access point to thecommunity where she presents her credentials. Through theaccess procedure, the user obtains a certificate for the VC. Thecertificate is needed in later interactions within the communityand it represents a VC-level access control. Any authenticatedVC member can expose services to the community. Theseservices can only be found and accessed through a validcertificate. The service owner can provide further service-levelaccess control (i.e. in addition to certificate access control) byenforcing an access policy.

The registration and discovery of (user) services is donethrough a repository service, which leads to less overheadthan broadcasting a query. In addition it relieves the userside from maintaining a view on the available services and itprovides better protection of privacy since queries only reachthe repository.

Once services are discovered they can be orchestrated intoan application. An orchestrator is a special service that iscapable of using discovered services. In its basic form thismeans connecting service interfaces (i.e., connecting a pro-vided interface of one service to a required interface of anotherone). A more elaborate orchestrator may add some logic,effectively acting as a service consumer and may expose a newservice composed from other services. Building an orchestratorcan be entirely the responsibility of the user. Alternatively, thecommunity may provide an orchestrator service which takesa description of the orchestration as input and subsequentlyrealizes the orchestration. This allows for sharing standardfunctionality that each orchestrator needs and supports furtherstandardization of service interfaces.

Finally, a VC supports quality of service monitoring. A userwill experience a certain quality of a service she is using.This quality is monitored and recorded by a special servicewhose result can further be used for selecting a service. Userbehavior related to VC policies is also monitored, so that ausers reputation is maintained.

In summary, a VC is defined by the following core com-munity services. The entry point is formed by the VCEntryservice that returns access points for the other VC services,as well as a certificate. This certificate is obtained from theCertificateMgt service. The certificate certifies that the user

is indeed a member of the community as well as her accessrights. The certificate can be decoded using the public key ofCertificateMgt. Registered members can register and query theRepository service. An Orchestrator service supports settingup orchestrations as the means to use services. Behavior withinthe community and delivered service quality is monitored bythe CreditMgt service.

Although we describe these services as just single instances,replication is possible for scalability and reliability. Internalconsistency protocols must then be in place. However, theseare standard solutions and beyond the scope of this paper.

A service-oriented architecture brings the problem thatownership of a device that runs a service does not implycontrol right of the usage of that service, since access toa service is via the network. For reliable operation, serviceregistration should therefore come with a contract or resourcebudget that the service is sure to have on its platform. VCservices can partly or entirely be deployed as either networkedor network services. This leads to service access and discoverybeing either in the operator domain or in the user domain.We will analyse the two extreme cases and the hybrid casebelow, followed by our decision. In this comparison we usethe following criteria: i) confidentiality and integrity of servicediscovery control, ii) service access control, iii) reliability ofthe system, iv) trust in users and operators, v) costs for endusers and operators, and vi) scalability of the architecture interms of response time.

A. Deployment as user services

In this deployment scenario all VC services are deployed onuser devices (e.g. PCs, mobile phones, handhelds or ConsumerElectronics equipment). This scenario gives the end user fullcontrol of how service discovery, access control and orchestra-tion are implemented, and consequently full control of servicediscovery and service access. Little trust in the operator isneeded since all communication between the services can bedone over a secure channel, e.g. SSL.

A major concern is the intermittent connectivity of a user’sdevice and the possibility of the device being taken off-linewithout prior notice. If this device were providing a service,it would put the burden of overcoming such an event on theother end user devices in the VC, e.g., by replacing a coreservice with a substitute. These events also have implicationsfor the overall reliability of the system. In addition, the enddevices are typically resource constrained which may lead toslower 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 Ses-sion Control Function (CSCF) servers to reach the VC corecommunity services, e.g., a service registration will involveVCEntry, Repository and CertificateMgt. If VC core servicesare distributed among end devices, VC core signaling amongthem is required, which will lead to more signalling trafficcompared to the scenario where the services are co-locatedcentrally.

The operator would have little of service access and servicediscovery. The network would simply be used as a bit-pipewith the increased traffic as sole benefit. An operator wouldnot be considered a stakeholder in the widespread adoption ofthis architecture. Little standardization and cross-communityre-use of services can be expected.

B. Deployment as network services

The other extreme is to deploy all core community serviceson the application server of the IMS network. As opposed tothe dynamism of a mobile end device, the presence of theapplication servers and the core community services in theIMS network is much more stable. Hence, service discoveryand system maintenance become less of an issue.

From the user’s perspective, the functionality to implementVC properties would have to be provided by the operators, andconsequently the user would have little or no control of serviceaccess and service discovery. There is however little need forend users to carry the burden of system maintenance whichtherefore, increases the reliability of the system. Since theapplication servers typically have more resource available tothem and a certralized solution requires less VC core signaling,such a system is more scalable in terms of response time. Thisscenario uses less of the network’s bandwidth and thereforegenerates less charges for users.

From the operator’s perspective, by having control of allcore community services, they can choose how to implementthe IMS framework to meet their own financial objective onthe one hand, and their costumers’ expectations on the other.Control of all core community services gives an operator fullcontrol of service discovery and service access. With this,operators can better estimate the return on investment of theseservices, so that they can make an informed adjustment to theirbusiness model.

A particular point here is the position of the orchestrator. Ifit is deployed as a user service, it mainly serves as a meansto construct applications. When used as a network serviceit becomes easier for the operators to use the orchestrationinformation in resource allocation and control, since suchallocation is under full control of the operators. Althoughthis works fine for the simple orchestrations that just connectservices, it becomes more problematic to implement whenorchestration contains logic and even exposes services. Thishas to be managed by enforcing service agreements betweenusers and operators.

C. Hybrid deployment

In this scenario, some core community services are hostedby the operator and the others by the end users, dependingon the comparison criteria metioned above. A balance wouldhave to be found between the users ability to control theservice access and service discovery and the benefits of havingthe service hosted by the operator. Generic (parameterized)services which end users can inherit can be used to tailorcore community services according to the requirements ofthe user. An orchestrator is a good example of this: it takes

Fig. 1. The chosen hybrid deployment scenario of the core communityservices. Control of the VC is distributed over all three domains.

an orchestration description as a parameter to perform therequested setup as explained above. Another alternative isthat the VCEntry service is deployed as an IMS service.The operator guarantees to keep this gateway service runningsteadily. Meanwhile, an end user is allowed to choose hisown VC maintenance policy. A possible way to do this is tomake the VCEntry service capable of processing commandsuploaded by users. In this way, the burden of the servicediscovery, as well as maintenance of the overlay, could beshifted to the operator, while the users could remain in controlof the service discovery and the service access. The extent ofthis control would depend on which core community servicesare deployed in the operator’s domain as well as how thes areimplemented.

In hybrid deployment, a high level trust from operators toend users is required since the operators would be allowinguser-code to run inside their networks, which would thereforeincrease the complexity of service implementation. This trustcan be mitigated by making legally binding agreements be-tween the end user and the operator, and additional accesscontrol to core community services is mandatory.

Allowing end users to host various services on their owndevices would provide them with the highest extent of accessand discovery control of these particular services. This comesalong with increased data traffic to end devices boostingservice costs.

With the above analysis of the three different deployments,the hybrid deployment to form VCs in the IMS network isadopted in this paper. This deployment, depicted in Fig.1, givesend users more flexibility in how they choose to implementVCs, they have to loosely trust the operators, and they arerelieved of maintenance problem. The VCEntry is actuallyimplemented on a user device while other core communityservices including the CertificateMgt and the Repository, aredeployed in the operator’s domain. Other services registeredby members will be hosted on end devices. Due to the trustrelationship and the reputation consideration, the CreditMgt isunder the control of the operators. Operators can provide theirclients 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 overIMS, e.g., pictures and videos, she can firstly create a VC; theninvite her friends to join this VC; next register services whichcan provide this file sharing functionality; and finally set upa file sharing application through combining these registeredservices. Service use (application creation) in a VC is doneby an orchestrator which first discovers the required servicesfrom the repository, and then binds them together taking careof the service interfaces and protocols for connection andcommunication.

A. Virtual community forming

The VC formation process will be started once an initiativearises, e.g., file sharing among a group of trusted end users.The process of establishing a new virtual community is shownin Fig.2. In order to grant a creator control of service accessand service discovery, VCEntry, which facilities the memberregistration and service publication, will run in the end user’sdomain as a user service. Hence, the creator has the right todefine the join policy to the VC. After the VC is formed,the creator can broadcast the existence of this new VC to thenetwork or multicast to her friends.

Some of the core community services, including Certifi-cateMgt, Repository, and CreditMgt will be deployed in theoperator’s domain as core IMS services for the sake of thecostof system maintenance and of discovery. The Certifi-cateMgt service generates a signature for this VC whichwill be later used for member and service authentication.Repository acts as an intermediary between service providersand service seekers. Authorized VC members can discoverregistered services from this repository or register their ownservices for sharing. To deploy CertificateMgt, the creatorasks a deployer running on the application server to createor find an existing one and return the address. The same istrue for the deployment of Repository. The access points of

Fig. 3. VC member registration.

CertificateMgt and Repository will be advertised to VCEn-try. The shared secret of this VC, (e.g. the public key forauthenticating CertificateMgt’s signature), will be advertisedamong these core community services. In our implementation,all communication is done in SOAP, and all binary objects arefirst encoded into base64 so that they can be placed in theSOAP message.

B. Virtual community member registration

One of the main goals of forming a service-oriented VC inIMS is to keep the privacy of service providers and to securethe interactions among services. Therefore, service discoveryand access can only be done within the scope of a VC.An end user first needs to register as a member and onlythen she can see the presence of other registered services.To become a VC member, an end user (represented by adevice) needs to provide her profile to VCEntry and then themember registration process is activated. As shown in Fig.3, anapplicant’s profile is checked by VCEntry with the JoinPolicyto decide whether this user can be approved or not. If sheis approved, VCEntry will invoke CertificateMgt to registerher as a member of this VC. Upon the success of abovesteps, VCEntry will inform this new member about the accesspoints of both the Repository and the CertificateMgt, togetherwith the shared secret of this VC. With the access point ofCertificateMgt, the member can apply for tickets which isrequired for each activity happening in this VC.

C. Virtual community service registration and use

A VC member can now discover registered services usingthe Repository. To register a new service, a member can sendher service registration request to the Repository which willfirst check the validity of this member’s ticket and dependinon the outcome, register this service. Compared to a servicerunning outside a VC, a registered VC service is enrichedwith additional properties, like a black list and an accesscontrol list for making a local access control policy. Availableroles of members and corresponding actions are stored inthe access control list. Malicious user’s information can beinserted into the black list. As stated previously, the operatorscan provide the end users with added value if some core

Fig. 4. VC service registration.

Fig. 5. Secure service access.

community services are deployed as network services. Asan example, as part of the service registration this newlyregistered service will be assigned a credit value, for instance’threshold +1’ in Fig.4, by CreditMgt. This credit value willeither increase or decrease based on the behavior of a service.In this way,the behavior of a service and its provider can bemonitored. This is advantageous for both users and operators,as users can obtain better quality while operators can removebadly performing services. As a result, the trust between theoperator and the end users can be increased. Within the scopeof a VC, end users can build applications through composingthe registered services by the orchestrator. This orchestratordiscovers required services from the repository and binds themat runtime to create applications. During the execution of anapplication, SOAP messages exchanged between services willbe encrypted to be carried by SIP, as shown in Fig.5.

V. EXPERIMENTAL PLATFORM

In order to test the feasibility of this service-oriented VCoverlay in IMS, a file sharing example scenario is designed. Inthis scenario, an end user wants to share a picture stored on hermobile phone with her two friends. Considering the privacy ofthe content, she first creates a VC and then invites her friendsto join. She registers a file server service into the Repositoryof this VC. And her two friends, who are VC members, nowpublish their file sink services and mouse services into theRepository. She uses an orchestrator to bind the file serverservice with one of the file sink services and meanwhilesubscribes the orchestrator to the two mouse services for theirdouble click mouse events. After the application starts, thepicture will be transmitted from her mobile phone to oneof her friends’ mobile phone. The picture destination can beswitched to her other friend through a double click mouseevent generated by another mobile phone. In this scenario, wedeployed the VC core services and registered services in the

Fig. 6. Service deployment of the file sharing scenario. VCEntry is notconnected to other services because the member- and the service registrationare not shown. CreditMgt will be connected after the files have been shared.

Fig. 7. A screen flash of the file sharing scenario.

Fig. 8. Layered architecture of the experimental platform.

manner depicted in Fig.6. Fig.7 shows a physical deploymentand a screen flash of the file sharing scenario. Fig.8 illustratesthe proof of concept of our solution.

The example scenario was created using the standard-basedIMS network simulator with communication services emu-lators. The open Source Glassfish/SailFin JavaEE/SIP serverwas used as the network application server [12]. UIQ 3 SDKemulators [13] where used as end devices which use theEricsson’s IMS Client Platfor (ICP) for Open-OS devices thatextends JSR 281 standard [14]. The VC is created by anadministrator (Admin) to allow end users to become membersthrough an entry point. The same program also allows a fileserver (service provider) to share files with other users (servicerequesters) after joining the VC.

The application is in principal split into two parts. The mo-bile application can take on the roles of, an Admin/ VCEntry, aservice provider, or a service requester. The server application,which represents the network services, can function as adeployer, CertificateMgt, or a Repository. The deployer allowsthe Admin to create an instance of the CertificateMgt or theRepository. After creating the instance, it replies with the SIPaddress of the newly created instance.

Secure channels are created similar to how they are created

in existing SSL implementations. One of the key differenceswould be that SIP would be used as the transport protocol,particularly the SIP Message method.

VI. CONCLUSIONS

This paper introduces 5 services enabling mobile P2Pservice sharing in the IMS network. It presents an analysisof three system architecture alternatives for forming andmanaging virtual communities. For each of the alternatives,distribution of service discovery control and service accesscontrol among end users and operators is discussed, and prosand cons from both the user’s and the operator’s perspectiveare given. In addition, a proof-of-concept of a mobile P2P filesharing service is demonstrated.

The main contribution of the paper is the introduction ofthe VC concept and an orchestrator service in IMS. The mainbenefit for the user is the ability to control service sharing,while the main benefit for the operator is the possibility togenerate more revenue. The operators are in control of criticalservices and the system maintenance. Our future work willfocus more on the security of the complete system, as anextension to security of service access and service discoveryprovided here.

ACKNOWLEDGMENT

This work is supported by the COMET consortium fundedby the European Commission 6th Framework Programme.

REFERENCES

[1] P. Triantafillou and C. Xiruhaki and M. Koubarakis and N. Ntarmos,“Towards High Performance Peer-to-Peer Content and Resource SharingSystems”, Proc. of CIDR, 2003.

[2] F-U. Andersen et al., “An Architecture Concept for Mobile P2P FileSharing Services”, in Lecture Notes on Informatics (LNI) P-51, pp. 229-233, ISBN 3-88579-380-6, 2004.

[3] Digital Cellular Telecommunications System (Phase 2+), Universal Mo-bile Telecommunications System (UMTS), IP Multimedia Subsystem(IMS), Stage 2, V7.6.0, TS 23.228, 3GPP, Dec. 2006.

[4] http://www.3gpp.org, Oct. 2008.[5] J. Rosenberg, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Han-

dley and E. Schooler “SIP: Session Initiation Protocol,”, RFC 3261, IETFNetwork Working Group, http://www.ietf.org/rfc/rfc3261.txt, June 2002.

[6] M. Matuszewski, N. Beijar, J. Lehtinen, T. Hyyrylainen, “Mobile peer-to-peer content sharing application”, in 3rd IEEE Consumer Communi-cations and Networking Conference (CCNC), 2006.

[7] A. Liotta, L. Lin, “The Operator’s Response to P2P Service Demand”,in IEEE Communications Magazine, pp. 76–83, July 2007.

[8] Igor Radovanovic, Amit Ray, Johan Lukkien, Michel Chaudron, “Dy-namic mobile service provisioning in IP Multimedia Subsystem (IMS)using a Service Oriented Architecture”, in the Springer Verlag as a partof its Lecture Notes in Computer Science series (LNCS 4749), 2007.

[9] Shudong Chen, Igor Radovanovic, Johan Lukkien, “VICSDA: UsingVirtual Communities to Secure Service Discovery and Access”, in theSpringer Verlag as a part of its Lecture Notes in Computer Science series(LNCS 4577), 2007.

[10] X. Ye, J. Zhang, J. Wang, “Architecture of HIKEC: An IMS-basedMobile P2P File Sharing Service”, in Proc. of International Conferenceon Communication Technology 2006, ICCT ’06, pp. 1–4, Nov.2006.

[11] I. Stoica et al., “Chord: A scalable peer-to-peer lookup service forinternet applications,” in Proc. of the 2001 conference on Applications,technologies, architectures, and protocols for computer communications(SIGCOMM’01), Vol. 31, No. 4, pp. 149-160, Oct. 2001.

[12] https://glassfish.dev.java.net/, Oct. 2008.[13] http://developer.uiq.com/, Oct. 2008.[14] Sun Microsystems, JSR 281 IP Multimedia Subsystem (IMS) Services

API, Public Draft version 0.9, Sep. 2007.