Proc. of World Cong. on Multimedia and Computer Science Model-Based Social Networking Over Femtocell Environments 1 Hajer Berhouma, 2 Kaouthar Sethom Ben Reguiga 1 ESPRIT, Institute of Engineering, Tunis, Tunisia 2 INNOV COM LAB, SUPCOM, Tunis, Tunisia Abstract: Social networking is a new evolving paradigm that allows a set of actors to communicate over a commun structure. Networked femtocells called femtozone can be considered as a common structure that delivers a new class of value added services running in high data rate network.heterogeneity of services and their corresponding devices is a major challenge of such communication specifically in service discovery.in this work we have presented the MDA tool (Model driven architecture) as a solution to ensure homogeneity between femtozone services. Keywords: femtocells, MDA tool, UPnP. I. INTRODUCTION Femtocell, also called home base-stations, is a short range, low cost and low power base-stations, installed by the consumer for better indoor 3G voice and data reception. The user-installed device communicates with the cellular network over a broadband connection such as DSL, cable modem, or a separate RF backhaul channel. Beyond the traditional business drivers of improved indoor coverage and capacity savings, femtocells have a strong appeal as a delivery platform for a new class of value-added services. These services are referred to as femtozone services to distinguish them from the vanilla voice and data access services provided by the femtocell. These applications have the advantages of being running in a high data rate network through femtocell dedicated large bandwidth. The boundaries of the ubiquitous environment covered by this femtozone services varies from one user home to many neighbors homes that communicate together through large variety of devices types. The femtozone service ecosystem is still at a nascent stage. However, it can become a very powerful social networking tool (figure 1). The grouping may be static or dynamic. The femtocells in a group are logically connected to one another, but may also have peer-to-peer connectivity among them. An individual femtocell may belong to more than one femtocell group. An example of an application enabled by femtocell is friend and family, in which a parent could be notified of their child s arrival or departure from a friend s home, in addition to their own ability to share photos automatically; and ability to stream videos or TV directly to the group (football match ). To build femtozone system, industrial and academic communities are required to address two major and complementary infrastructural challenges: networks and services. This article focuses mainly on the second challenge (i.e., services) with a particular focus on one of the critical enabling techniques to implement service adaptability: service discovery. DOI: 02.WCMCS.2013.1.19 Association of Computer Electronics and Electrical Engineers, 2013
Existing service discovery mechanisms have adopted various service-description languages, thus limiting the scope of global service discovery over neighbors -with heterogeneous equipments. Though each of them has its advantages and disadvantages in terms of expressiveness and query efficiency, they are primarily bound to the architecture of the individual discovery mechanism. A unified way for service description is needed while hiding heterogeneity. Motivated primarily by the above considerations, this article introduces a novel methodology for application development over femtozone that is Model-driven Architecture based. Figure1: Networked femtocell II. SYSTEM CHALLENGES The most challenging characteristic of the social networking is the heterogeneity. Devices communicate with a multitude of communication mediums and protocols. In the femtozone scenario the underlaying communication medium is the femtocell link layer standard which offers a high bandwidth and poor BER. As for protocols, a variety of issues need to be more investigated. Given the resource-constrained nature of mobile devices (e.g., memory, CPU) when compared with their desktop PC siblings, it is impossible for mobile devices to maintain as many services as stationary desktop PCs do. On the other hand, users would naturally like their services to follow them wherever they are and whatever devices they are on. As a result, femtozone applications will need to be integrated seamlessly to provide disruptive and consistent services to user s satisfaction. A. Service discovery In the scenario described in previous section, when a person needs for example to watch a football match, his TV (client device) must be able to find a service provided by one or more neighbor over the femtocell network (server device). The main task of this service is to read local data in live (streaming). The client TV usually has no idea which device implements the service. The important point here is that the service with specific properties is available and accessible. This scenario is a typical example of service discovery. Even similar devices supporting the same services represent their capabilities in a different representation format and content. Such heterogeneity along with the protocols layers diversity, prevent applications to use any available equivalent device on the network to accomplish a specific task. Different protocols can cohabit in the same netwok UPnP [UPnP], IGRS [IGRS ] and DPWS [OASIS] and offer same functionalities like for example discovery and description of devices (device id, friendly name, manufacturers etc) along with their supported services and capabilities. However the way these functionalities are presented is different. The device and service description heterogeneity, prevent applications to use any available equivalent device on the network to accomplish a specific task. Service discovery process is implemented in the following way: An application or device that needs a certain service sends a request describing the required properties of the service to a specific multicast address (and port number). 234
Other applications or devices on the same network receive the request, and if they provide the requested service themselves (or know another device that implements the service), respond with a message describing where the service can be found. The application or device searching for the service collects all responses, and from the responses chooses the one service provider it is going to use. In addition, devices that join or leave a network can send announcements to other devices describing the availability of the services they provide. To illustrate this problem, we take the example with friend and family application in the case of football match streaming. The user belonging to the neighbor group client TV has received a response to his request for the service that will allow her watching the match. But the concerned server TV describes his services with a different language compared to the one of the client TV. Specifically, client TV supports the UPnP protocol that uses an XML based format while server TV supports the DPWS protocol that uses the WSDL (Web Service Description Language) to expose the service descriptions. Other than the description format, the syntax content is not the same. The services and the actions have also different syntax, the UPnP TV offers a "Watch" service with a "read" action to read data, while the DPWS TV uses the action "steaming" to offer the similar functionality. Devices arriving to a such environment are expected to identify other devices along with their services and integrate them regardless their protocol for service description so they can be used transparently by users, other devices or applications. III. PROPOSED SOLUTION A. The MDA tool Model-Driven Architecture (MDA) [Hagget 67] is an approach to IT system development fostered by the OMG. Its essence is the concept of separation between the specification of a system s essential functions as a platform-independent model and the realization of the system using more specific and detailed platform as a platform-specific model. Its promising platform-, language-, and middleware-neutral features can have a great impact on the current methods and techniques applied to manage the software development process. A layered model architecture is proposed by the Model Driven Architecture (MDA) [OMG 03] which is promoted by the Object Management Group (OMG). The MDA provides a four layer architectural modeling space: M0 as the instance layer, M1 for the model, M2 for the meta-model and the M3 for meta-model layer. The M0 layer represents objects from the real world, such as a real TV. At the M1 layer, a drawing of a printer abstracts the printer from the real world. Thus, the printer's drawing is a model abstracting an object from the real world. The M2 layer, the meta-model layer specifies the basic concepts to be used by the underneath layer. Thus, each model (i.e. drawing) at the M1 layer is constituted only of concepts from the meta-model such as a circle or a triangle. Therefore, models (i.e. drawings) at the M1 layer are conformed to the M2 layer since they are constituted only from the specified concepts at the M2 layer. The M3 layer also defines concepts to be used by the M2 layer models and so on. The MDA defines standard models and languages like the Unified Modeling Language (UML) [OMG 97] to specify concepts at the M1, M2 and the Meta Object Facility (MOF) [OMG 06] to specify concepts at the M3 layer. Additionally, relations between concepts along with the allowed cardinality are specified by each upper layer. The Model Driven Architecture is considered as a specific instantiation [Bézivin 05] of the Model Driven Engineering. The MDE [Schmidt 06] is a software development methodology based on different levels of abstraction aiming to increase automation in program development. The basic idea is to abstract a domain with a high level model then to transform it into a lower level model until the model can be made executable using rules and transformation languages like in template-based code generation tools. The MDE is used to improve software development through automatic code generation from higher to lower layers. Metamodels can also be used to unify heterogeneous representations by providing them a common language in order to facilitate communication and to assure interoperability. B. Model based plug and play protocol interoperability Devices supporting a "Plug and Play" protocol publish their capabilities and type on the network. More precisely, a device is constituted of three entities. The first is the protocols stacks used to communicate and interact with other devices and applications. The second entity consists in the provided services which 235
represent the devices' capabilities. And finally, the third entity is the device and service description which are announced on the network. Based on the announcements, the applications deployed in the home network discover the provided services and interact with devices and applications to accomplish a specific task. Currently, the following two plug and play protocols are widespread: UPnP and DPWS. Even though those protocols have a lot in common, applications and devices can not cooperate due to the three following differences: each plug and play protocol proposes its own device annunciation and description format. Each protocol provides a standard content description per device type. The content description includes the device type name, the required supported services names and versions. The standard content description also defines the names of the supported operations on the device along with their input/output parameters names, types and ranges. Thus, two standard equivalent devices such as the printers, supporting different plug and play protocols announce a syntactically different but semantically equivalent content. Figure 2: Service discovery with Model Driven Architecture To tackle the devices heterogeneity and to accomplish interoperability between plug-n-play devices and applications, we propose to use the MDA model. The figure 2 illustrates this scenario for service discovery between UPnP and DPWS client for TV watching in femtozone scenario: In order to allow UPnP requests to understand non UPnP devices (i.e. DPWS), a common language must be used by both sides. Model transformations provide the way to transform one model to another. Figure 3 is an example of an UPnP TV device description with his corresponding services taken from [Felix]. This description is considered as a model instance of the UPnP metamodel. To illustrate our idea, we have partially defined the general metamodel with only two concepts: device and service. As it is described in the same figure the general request model will be automatically generated from elements of the UPnP request model by model transformation. The general request model has been modeled by the eclipse modeling framework [EMF]. Once the two descriptions are written in the same language, communication between the two devices will be easier. However this step, doesn t resolve the entire problem by providing the adequate response of the request. In fact, like it is described in the following figure, similarity search techniques are considered as the second step of our service discovery process in order to find the adequate device and service. 236
Figure 3: An example of UPnP service discovery transformation IV. CONCLUSION Devices in femtozone scenario supporting a plug-n-play protocol announce their hosted services each in its own description format and data content. Even similar devices supporting the same services represent their capabilities in a different representation format and content. Such heterogeneity along with the protocols layers diversity, prevent applications to use any available equivalent device on the network to accomplish a specific task. The contributions of this thesis focus on providing to the applications targeting specific devices, with specific protocols, the ability to interact with any equivalent device on the femtozone. In other words, our approach provides semantic and behavior interoperability between two equivalent devices based on the mda model. REFERENCES [1] [UPnP ] UPnP. Universal Plug and Play. http://www.upnp.org/. [2] [IGRS ] IGRS. Intelligent Grouping and Resource Sharing. http://www.igrs.org/ [3] [OASIS] OASIS. Devices Profile for Web Services Version 1.1. http://docs.oasis-open.org/wsdd/dpws/1.1/os/wsdddpws-1.1-spec-os.html, 2009. [4] [Hagget 67] P. Hagget & R.J. Chorley. Models, paradigms and new geography. In Models in Geography, Methuen, London, 1967. [5] [OMG 03] Object-Management-Group OMG. MDA Guide Version 1.0.1., 2003. 237
[6] [OMG 97] Object-Management-Group OMG. UML Specification version 1.1. www.omg.org/cgibin/doc?ad/97-08- 11, 1997. [7] [OMG 06] Object-Management-Group OMG. Meta Object Facility Specifications. www.omg.org/spec/mof/2.0/, 2006. [8] [Bézivin 05] Jean Bézivin. On the unification power of models. Software and System Modeling, vol. 4, pages 171-188, 2005. [9] [Schmidt 06] D.C. Schmidt. Guest Editor's Introduction: Model-Driven Engineering. Computer, vol. 39, no. 2, pages 25-31, February 2006. [10] [Felix] Apache Felix. http://felix.apache.org/ [11] [EMF] Eclipse Modeling Framework Project (EMF). http://www.eclipse.org/modeling/emf/ 238