Ambient Networks (ANs) are dynamically changing and heterogeneous as they consist of potentially large numbers of independent, heterogeneous mobile nodes, with spontaneous topologies that can logically interact with each other to share a common control space, known as the Ambient Control Space. ANs are also flexible i.e. they can compose and decompose dynamically and automatically, for supporting the deployment of cross-domain (new) services. Thus, the AN architecture must be sophisticatedly designed to support such high level of dynamicity, heterogeneity and flexibility. We advocate the use of service specific overlay networks in ANs, that are created on-demand according to specific service requirements, to deliver, and to automatically adapt services to the dynamically changing user and network context. This paper presents a self-management approach to create, configure, adapt, contextualise, and finally teardown service specific overlay networks

Cheng, L

Galis, A

Jean, K

Mathieu, B

Ocampo, R

Song, M

English

UCL Discovery

Self-Management ofContext-Aware OverlayAmbient NetworksBertrand Mathieu, Meng SongFrance Telecom R&D2 Av. Pierre Marzin, Lannion, France{bertrand2.mathieu; meng.song}gorange-ft.comAlex Galis, Lawrence Cheng, Kerry Jean, RoelOcampoUniversity College London, Electrical Engineering Dept.Torrington Place, London, WClE 7JE, United Kingdom{a.galis, 1.cheng, kjean,r.ocampo}gee.ucl.ac.ukMarcus Brunner, Martin Stiemerling, Marco CassiniNetwork Laboratories,NEC Europe LtdHeidelberg, Germany{brunner, stiemerling, cassini}gnetlab.nec.deAbstractAmbient Networks (ANs) are dynamically changing andheterogeneous as they consist of potentially large numbers ofindependent, heterogeneous mobile nodes, with spontaneoustopologies that can logically interact with each other to share acommon control space, known as the Ambient Control Space.ANs are also flexible i.e. they can compose and decomposedynamically and automatically, for supporting the deployment ofcross-domain (new) services. Thus, the AN architecture must besophisticatedly designed to support such high level ofdynamicity,heterogeneity and flexibility. We advocate the use of servicespecific overlay networks in ANs, that are created on-demandaccording to specific service requirements, to deliver, and toautomatically adapt services to the dynamically changing userand network context. This paper presents a self-managementapproach to create, configure, adapt, contextualise, and finallyteardown service specific overlay networks.Keywords: overlay network, self-management, context-aware,ambientnetworkI. INTRODUCTIONThe concept ofAmbient Networks (ANs) introduces a newkind of mobile networks, formed by heterogeneoususer/network devices and using different networkingtechnologies. ANs can range from small size ad-hoc networksto much larger wireless networks that cover variousadministrative boundaries or domains. The major novelty ofANs is that they can compose and decompose with other ANsdynamically. (De)composition of ANs therefore extends anetwork's capability, to provide different types of (new)services to end users, by composing different (service) modulesdepending on the user context.We advocate the use of overlay networks to enable thecomposition ofservices and to support the subsequent deliveryof services to end-users in ANs. In this paper, we present theconcept of Service-aware Adaptive Transport Overlays(SATOs) for ANs, which are created for delivering a givenrequested service. Given that ANs are very dynamic,heterogeneous, and flexible, a self-management approach is anatural way to manage SATOs. The SATO self-managementsystem collects distributed user and network context in an AN,and automatically assigns dedicated nodes to analyse theseinformation, in order to support the setting up, andsubsequently the adaptation ofSATOs.This paper briefly introduces the main concepts of ANs,before focusing on SATO, its lifecyle and explaining its self-management. The following section sums up some evaluationresults and section 5 concludes this paper.II. SATO INAMBIENT NETWORKSA. Description ofAmbientNetworksThe Ambient Networks (AN) project [1] seeks to studyambient networks taking into consideration aspects like multi-radio interfaces, mobility management, security issues,composition of ANs, context management and servicedelivery [2]. The main task is to design an overall architectureenabling the user-centred delivery of service, any time,everywhere, whatever the device and the network are. Theentity that gathers all the information and links them is calledthe Ambient Control Space (ACS) (Figure 1: The ACS, OM FE andSATO. It can be seen as a control framework that manages allcharacteristics of ANs, provides abstraction of the resourcesand enables the service delivery for ANs.A service interface, the Ambient Service Interface (ASI) hasbeen defined as an "upper layer" interface ofthe ACS that isaccessible to applications to define their requirements andspecify how the service should be delivered (in terms ofQoS,security, connectivity). The management of this request isperformed by the Overlay Management (OM) FE [4][5]. TheOM FE will then create and maintain a service-specificoverlaynetwork to fulfil the service provider requirements andto manage the service delivery to end-users while adapting touser and network context. This specific overlay is called a1-4244-0799-0/07/$25.00 t2007 IEEE 749Service-aware Adaptive Transport Overlay (SATO) network.The Service Context (SC) FE [3] is also very important in thiswork since the SATO should adapt automatically to context.Meda ApliatinsI ServicesASIOvefl CotetavyNao~ANFigure 1: The ACS, OM FE and SATOB. SATO Overlay NetworkSATOs are service specific, as they take into accountspecific requirements, specific resources (and other supportiveservices) in the network that are needed tosupport/operate/manage the delivery of a particular service toend-users. The services are assumed to be designed in amodular and fine-grained way. This leads to elementaryservices modules that are distributed in the overlay networkand composed by OM FE for providing the overall service.The composition is performed by configuring the overlayrouting tables in such a way that the data passes through themodules in the right order. Those services modules are calledSatoPorts (SPs) and can then be viewed as the necessaryresources or supportive services or service computationresources that are needed for deploying a (new) end userservice (Figure 1: The ACS, OM FE and SATO [6]. Examples of SPsare application processing modules such as transcoders, cache,virus scanning, security services or application control datasuch as a P2P SIP (Peer-to-Peer Session Initiation Protocol)network [7] but can also be networking service such as QoS-control services. SPs are hosted on nodes that should beincluded in the SATO to ensure the good delivery of theservice. Those nodes are called SATO Overlay Nodes (SON).The OM FE is a distributed entity. Each SATO node hostsa part of it, the SATO manager. The SATO manager is incharge of the management of the SATO (setup, complexadaptation, teardown) but specific tasks are delegated to othermodules. For instance, the SATO routing algorithm respondsto simple context changes which can be resolved by simpledata re-routing within the same SATO overlay networktopology. Finally, the SON Local Resource Manager andcontext sensors (bandwidth sensors, Flow sensors...) aredesigned in the SON to monitor and collect specific resourcesand to provide information related to the current context to theOMFE.III. SELF-MANAGED SATOsThis section presents how a SATO is self-managed, howcontext information is managed and the solution for the threesteps ofthe lifecycle ofthe SATO, i.e. the establishment, theadaptation and the teardown.A. Characteristics ofANs to take into accountsThe setup and maintenance of simple overlay networks istypically not seen as a big problem in fixed networks.However, in wireless and dynamic networks, topologies andnetwork characteristics dynamically change all the time,making the setup and maintenance a tricky problem.Furthermore for Ambient Network, where ANs candynamically (de)compose. The SATO overlay networks aretailored towards the specific requirements ofa service delivery,and with it, the topology of the overlay network is alsodependent on the service running within the SATO overlaynetwork.B. A DHT-basedapproachfor managing Context Co-ordinatorsBearing in mind all those characteristics, it clearly appearsthat to setup SATOs, there is a need for a monitoring system tobe aware of the current context (by collecting and processingrelated real-time network information, known as aggregation inthis paper) and a management system to use the processedinformation to setup (and subsequently to manage) SATOs.The challenge of enabling aggregation in ANs is that weneed to dynamically select a (or a set of) node(s) to becomeresponsible for collecting and subsequently analysing thecollected information. In other words, we need some "co-ordinators" in the network, each responsible for managing (i.e.aggregating) a type ofdistributed data, and serves clients uponrequests. Since the broadcasting ofinformation to AN nodes isnot scalable and since static assignment ofCo-ordinators is notreliable in wireless and changing environments, we suggest thesolution ofthe dynamic election of "co-ordinators" by utilisingthe dynamic and scalability advantage ofDHTs.C. Context Management . How to aggregate contextinformation in Context Coordinators?We define the different types ofaggregated information ascontext, and assign each with a Universal Context Identifier(UCI) [8] . A UCI is a String identifier similar to a UniformResource Identifier (URI) and uniquely identifies a type ofcontext. We assume that each AN node has a set of sensors(not necessary a complete set of sensors) that are capable ofmonitoring different types ofcontext.* Start ofthe Overlay SensorsDuring bootstrapping of an AN, the distributed sensors in thenetwork will start collecting the type of context that they areresponsible for (step 0 in Figure 2). The collected context willbe stored locally. The sensors register themselves with thelocal Context Co-ordinator (ConCoord) (step 1 in Figure 2).The sensor registration process involves registering the UCI ofthe type of context that the sensor is responsible for, andoptionally a network location identifier that the sensor wishes750to be identified by other nodes in subsequent communications(i.e. IP).E. SATOEstablishmentOnce the SATO Manager has received the aggregatedcontext that it has previously subscribed for, it can begin toestablish a SATO by communicating with the nodes on whichthe located SPs are hosted (i.e. negotiation on overlay IDs,security parameters... etc.). Figure 3 shows differentestablishment ofSATOs in an AN.SATO 3 SO_* ~SON 2SA TO-2 S !1 (6) Query(0)Underlying network (AN)Figure 2 A SATO establishment process* Dynamic Aggregation Node Determination throughConCoordThe ConCoord then begins a distributed query process (step 2in Figure 2) to identify which nodes in the AN to beresponsible for aggregating, and subsequently disseminatingthe type of (aggregated) context that the sensor has justregistered with (identified through the UCI provided by thelocal sensor). A matching ofthe UCI and the DHT's keyspaceenables AN nodes to know if they are responsible foraggregating the type ofcontext information represented by theUCI.For reliability, it is worth mentioning that the aggregationresponsibility is automatically transferred to another node inthe AN, should the original responsible node fails. Thanks toDHT principles, automated aggregation responsibilityrecovery is achieved, without any form of real-time re-negotiation between theremaining nodes.D. ContextResolutionWhen receiving a setup request (step 3 in Figure 2), theOM FE first analyses the request to know the applicationrequirements (e.g. required QoS or security policies) and theneeded intermediate services modules...(step 4 in Figure 2).The result of this analysis is a list of context criteria and aservice chain, composed of the required SPs to deliver theservice. The Aggregation Co-ordinator (a.k.a. the SATOManager) will then query its local ConCoord through asubscription process (step 5 in Figure 2). The SATO managersubscribes to the ConCoord with the UCI(s) ofthe type(s) ofaggregated context that it needs to establish a SATO. TheConCoord then begins a distributed query process (step 6 inFigure 2) to identify which nodes in the AN are responsible foraggregating the type of context that the SATO Manager hasjust subscribed to. The ConCoord on the same node as theSATO manager will retrieve the aggregated context from theaggregation node. The SATO Manager will then trigger adistributed aggregation process to establish a correspondingSATO (see later).Figure 3 Different SATOs in an ANF. SATOAdaptationThe SATO must be self-adaptive, which means that whenchanges in network context have taken place, the SATO shouldbe capable of carrying out dynamic re-configuration. Thechange of context can be detected by the components of theSATO, like the QoS sensor, the flow sensor or triggered byexternal entities of the ACS, like the context or the mobilityFunctional Entities. Changes in the context may just imply are-calculation of the route between SPs, done by the SATOQoS routing algorithm when the QoS is no longer ensured onthe current path (overloaded link, failure of nodes...). Moreimportant context changes (user's mobility, user's change ofdevice or when Ambient Networks compose) can lead to theneed to add, remove SPs in the overlay in case the currentavailable SPs do not offer such functions. In this case, theadaptation process is similar to the establishment processincluding the discovery oftheneeded SP.G. SATO TeardownWhen it is no longer needed, the SATO should be torndown, in order to release unused resources in the overlaynodes. Three different cases can be considered: 1) when SATOserver endpoints cause the SATO to be destroyed; 2) when theduration for which the SATO was set up is over (if notextended) ; 3) When endpoints did not leave properly or failedIV. EVALUATION OF THE SOLUTIONIn this section, an evaluation ofthe efficiency for lookingup context aggregators and ofthe reliability and scalability ofthe solution is presented. Using the CAN protocol [9] for theDHT, we have developed a CAN-DHT simulator that creates2-dimensional CAN-DHTs of different network sizes, andgenerates a graphical display ofthe DHT keyspace ownership.We have also developed a "SATO Manager" management751simulator, which takes different values of the neighbourhoodscale N (see later), then simulates the activation of SATOManager(s) on different number of overlay nodes in the DHTaccordingly, and returns the total number of a particular typeof SATO Manager that are currently running.8705025 75 125 175 225DHT overlay network sizeThe SATO Manager approach -Poly. (The SATO Manager a roachFigure 4 Average overlay hop count Vs. DHT overlay network sizeThe results in Figure 4 suggests that the SATO Managerapproach is efficient: only few overlay hops are needed for aConCoord to reach an aggregation node of interest. Note thatthe slope of the curve in Figure 4 gradually decreases as theDHT overlay network size increases. This suggests that theapproach is scalable.The SATO Manager approach should be robust to handleheterogeneity and dynamicity in ANs: that means that in thecase of a failing node, the node is "backup" by its immediateoverlay neighbours. The evaluation is carried out over anetwork of 100 overlay nodes. We assume that anadministrator would like to have 10% of the nodes in thenetwork to be the hosts ofa particular type ofSATO Manager.The failure rate ranges from 0% to 80%.* 0% failurerate m 20% failurerate A 50% failurerateo 80% failure rate -Poly. (0% failurerate) -Poly. (20% failurerate)-Poly. (50% failurerate) -Poly. (80% failurerate) - - Linear(Threshold)Figure 5 Comparison between robustnessThe result of Figure 5 proves that the total number of activeSATO Managers (of the same type) that are available at onetime in the network can be made constant under differentfailure rates. For example, when the network is extremelyheterogeneous and mobile e.g. with 80% failure rate, we canadjust N=4 to achieve a desired level of robustness i.e. toachieve a desired number ofcapable nodes in the network (i.e.to have 10 capable nodes in the network at one time, asdefined by the administrator). Therefore, the provisioning ofN(or M) in SATO Manager approach provides the necessaryfacility to adjust the level ofrobustness.V. CONCLUSIONThe self-management of context-aware SATO overlaynetworks, presented in this paper, enables the setup,maintenance and teardown ofSATOs in a completely dynamicand context-aware manner. To manage the context, threeconcepts have been presented: the sensors that are in charge ofcollecting information, the Context Coordinators, who are incharge of storing and aggregating the context and a scalableand decentralised approach that dynamically determine whichnode in the network is an aggregation node for a type ofcontext. This approach relies on the DHT principles, fordealing with large networks and reliability and load balancinghas been evaluated. The setup of SATOs, retrieving thecontext from the context coordinators, the adaptation, via theoverlay routing protocol or via the OM FE and the teardown,triggered or automated, have been presented.VI. ACKNOWLEDGMENTThis paper describes work undertaken in the context of theAmbient Networks (Phase 2) - Information SocietyTechnologies project, which is partially funded by theCommission ofthe European Union.VII. REFERENCES[1] EU-IST project 507134 Ambient Networks, http://www.ambient-networks.org[2] N. Niebert, et al, "Ambient networks: An architecture for communicationnetworks beyond 3G," IEEE Wireless Communications, vol. 11, pp. 14-22, IEEE, April 2004.[3] R. Ocampo, L. Cheng, Z. Lai, A. Galis, "ContextWare Support forNetwork and Service Composition and Self-adaptation", in Proceedingsofthe 2nd International Workshop on Mobility Aware Technologies andApplications (MATA) 2005, Montreal, Canada, October 2005.[4] L. Cheng, K. Jean, R. Ocampo, A. Galis, "Service-aware OverlayAdaptation in AmbientNetworks", International Multi-Conference onComputing in the Global Information Technology (ICCGI) 2006,Bucharest, Romania, August 1-3, 2006.[5] T. Petersen, et al., "SMART - Final Architectural Design", IST-2002-507134-AN/WP5/D03, http://www.ambient-networks.org/publications/D5 3 SMART Final Architectural Design_PU.pdf[6] B. Mathieu, M. Kleis, M. Song, " A P2P Approach for the Selection ofMedia Processing Modules for Service Specific Overlay Networks",International Conference on Internet and Web Applications and Services,Workshop on P2P Systems and Applications (ICIW P2PSA 2006),February 23-25, 2006.[7] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings, "A P2PApproach to SIP Registration", draft-bryan-sipping-p2p-02.txt, March2006[8] K. Jean, L. Cheng, R. Ocampo and A. Galis, "Contextualisation ofManagement Overlays in Ambient Networks ", International Multi-Conference on Computing in the Global Information Technology(ICCGI) 2006, Bucharest, Romania, August 1-3, 2006.[9] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker,"A Scalable and Content-Adressable Network",. In Proc. ACMSIGCOMM, San Diego, CA, USA, Aug. 2001752

A P2P Approach for the Selection of Media Processing Modules for Service Specific Overlay Networks&quot;,

A P2P Approach to SIP Registration&quot;,

A Scalable and Content-Adressable Network&quot;,. In

Ambient networks: An architecture for communication networks beyond 3G,&quot;

Contextualisation of Management Overlays

ContextWare Support for Network and Service Composition and Self-adaptation&quot;,

Service-aware Overlay Adaptation in AmbientNetworks&quot;,

SMART - Final Architectural Design&quot;,

Self-management of context-aware overlay ambient networks

Self-management of context-aware overlay ambient networks

Abstract

Similar works

Full text

Available Versions

UCL Discovery