The Role of Ambient Networks in the Next Generation of Wireless Systems
Dept. of Informatics
Alluri Institute of Management Sciences
4G networks will demand the seamless integration of technology into the user environment. Such networks are envisioned to be an evolution and convergence of mobile communication systems and IP technology, requiring the support for heterogeneity in network access, communication services, and user devices. The Ambient Networks are used to solve these heterogeneous networking problems with a uniform process,
Network Composition, in a plug and play way.
In this paper we consider the Network Composition and analyze the gaps in today’s technology, and highlight the advantages of the Composition process. These networks will enable scalable and affordable wireless networking while providing pervasive, rich and easy-to-use communication. Ambient Network architecture for the handling of triggering events, which form the input for handover decisions and other mobility actions in the context of Ambient Networks. The Ambient Networks capable with the dynamics of both topology and traffic demands. Finally we describe the self-management approach to create, configure, adapt, contextualize, and finally teardown service specific overlay networks.
Keywords: self-management, handover management, heterogeneous networks, mobility management, trigger Access Networks, Network Composition
The Ambient Networks (ANs) [1, 2], a future networking architecture, which aims to enable the cooperation of heterogeneous networks belonging to different technology or operator domains. The architecture introduces a common control space (ACS) for all networks, which comprises of several functional areas (FA) allowing the diversity of implementations. Mobility management is an integral part of the Ambient Networks architecture, including the means for triggering and managing the mobility of various mobile entities able to move in multiple dimensions. The triggering framework will be a key enabler for seamless mobility by collecting a large number of triggers and hints in order to perform accurate and justified handovers maintaining user communication undisrupted. The framework will be flexible and can be used by other mobility functions as well. In the context of the Ambient Networks Project we aim to solve these heterogeneous networking scenarios in a unified framework. We call such networking of networks Composition. The heterogeneity arising from the different technologies is embraced such that the composition process appears homogeneous to the users. The vision is to allow composition of networks on-the-fly, transparently and in a plug and play manner, without the need for pre-configuration or offline negotiation.
In this paper, we present The SATO self-management system collects distributed user and network context in an ANs, and automatically assigns dedicated nodes to analyze these information, in order to support the setting up, and subsequently the adaptation of SATOs. As ambient networks compose and decompose the topology and traffic patterns can change rapidly. This means that one cannot rely only on long-term network planning and dimensioning that are done when the network is first built. Traffic engineering mechanisms are needed to adapt to changes in topology and traffic demand and dynamically distribute traffic to benefit from available resources.
2. AMBIENT NETWORK CONCEPTS
Composition achieves dynamic automated interworking of networks on the control plane, in addition to the data plane cooperation possible today. Data-plane co-operation provides basic addressing and routing services, control plane internetworking encompasses additional capabilities including mobility management, security and QoS control. It generalizes and streamlines many existing basic concepts like attaching a node to a network, mobility of nodes and networks (viewed as changing the composition structure) as well as typical interoperate network agreements. A detailed description can be found in .
Networks capable of composition are called Ambient Networks (ANs). An AN requires therefore an identity, a common control space known as the Ambient Control Space (ACS), and support for a specific control interface, the Ambient Network Interface (ANI). The ACS is an abstraction that consists of all the control plane functions of ANs. At an abstract level, the ACS has a modular structure, with independent – yet interworking – Functional Areas (FAs) for each control plane function. Thus there is a QoS Functional Area which contains multiple control functions, e.g. resource configuration, admission control etc.. Beyond this, there are few prescriptions as to how the ACS is realized, e.g. what functionality it actually supports, and how it is implemented.
Likewise, the ANI may be distributed over multiple physical network nodes, or it may be implemented by a single physical node.
Figure 1: The modular structure of the Ambient Control Space and the AN
When ANs compose, they communicate across the ANI to negotiate a Composition Agreement and create a composed AN. This process is orchestrated by the Composition FA. Composing ANs agree on joint control of all or a subset of their individual resources and on all policies that they are going to follow in order to coordinate their control planes. A composed ANs consists of all logical and physical resources that each constituent AN contributes. It has its own ACS controlling all its resources and communicating directly to the outside with its own identifier and via its own ANI. The ANI of composed ANs does not reveal its internal structure. This means composition is a recursive process that is always the same. It does not matter whether the composing ANs are themselves already the result of a composition. The ACS and the composition process are illustrated in Figs. 1 and 2.
The Generic Ambient Network Signaling (GANS) is the open base set of protocols enabling transport of signaling messages between FAs via the ANI. It is important to emphasize that GANS does not replace standard or de-facto standard protocols, which are used for instance to exchange routing information or for mobility support. GANS is used to exchange information currently not sufficiently covered by generally accepted protocols – e.g. Service Level Specification (SLS) negotiation between QoS FAs.
Figure 2: The formation of a new ACS upon composition.
2.1 ENHANCEMENT OF CURRENT TECHNOLOGY
While a lot of building blocks exist to realize this scenario today, a number of additional features are necessary. As a first step, all devices must be capable of screening their environment for devices that offer Internet access and mobile router functionality. Vice versa, these devices must advertise their capability. Furthermore, the mobile phone first acts as a mobile router, and the mobile router functionality is later transferred to the laptop. Additionally, the mobile phone automatically starts up the stateless DHCPv6 service to enable a synchronization of different configuration frameworks (UMTS and PAN). Whenever UMTS provides new or updated configuration parameters (e.g. DNS server addresses) they are automatically injected to the local DHCPv6 service to be distributed for the use of the PAN.
Figure 3: Configuration of a PAN
While the operation of the café’s access network can be realized with current technology, the initial configuration must be performed manually. It is not possible to install a dynamic, automatic agreement between café’s owner and the operator, detailing who is responsible for allocating addresses, authentication, accounting etc. This obviously is expensive and, furthermore, restricts the flexibility of the set-up. Likewise, the QoS reservation between café and operator is hard to adapt. As we will see in the next section, when the association between café network and operator network is regarded as a composition, the entire process can become automatic and dynamic, and moreover similarly in structure to the creation of the PAN described above.
3. AMBIENT CONTROL SPACE
Figure 4 illustrates the logical organization of the Ambient Control Space (ACS) internals, showing the functionality and interfaces that are its main features. The control space (large oval in Figure 4) consists of a collection of control functions, such as naming or composition agreement that cooperate to implement specific control functionality. These control functions exist within the overall control space framework.
Figure 4: Control space modularization and interfaces.
3.1 AMBIENT NETWORK INTERFACES
Higher-layer applications and services use the Ambient Service Interface (ASI) to access a subset of the control space functionality. This subset includes functions like naming, location and context management, inter-domain management and traffic engineering. The ASI provides an API to Ambient Networks that is located between the control space and the applications at a node. It allows applications and services to issue requests to the control space concerning the establishment, maintenance and termination of end-to-end connectivity. The ASI also exposes management capabilities and makes network context information available to the applications..
Connectivity resources interact with the control space through the Ambient Resource Interface (ARI), for example, to access multi-radio resource management, mobility and trigger processing. Finally, the Ambient Network Interface (ANI) facilitates communication between the control spaces of different networks, creating the shared, common control space that enables the advanced internetworking capabilities the Ambient Network project aims to achieve.
3.2 COMMON CONTROL SPACE FUNCTIONALITY
This common control functionality enables the plug-and-play interworking of the other control space functionality by providing a common architectural framework for intra-control-space communication, a control-space-wide resource registry and mechanisms for consistency management and conflict resolution. One piece of this common functionality enables different functions within the ACS to communicate by exchanging messages with one another. Message-based communication among a set of participants requires some infrastructure and mechanisms. Participants need unique identifiers to enable unambiguous message delivery.
Figure 5: Common control space functionality.
4. SATO IN AMBIENT NETWORKS
The Ambient Networks (AN) project  seeks to study ambient networks taking into consideration aspects like multiradio interfaces, mobility management, security issues, composition of ANs, context management and service
delivery . The main task is to design an overall architecture enabling the user-centered delivery of service, any time, everywhere, whatever the device and the network are. The entity that gathers all the information and links them is called the Ambient Control Space (ACS) (Figure 6: The ACS, OM FE and SATO. It can be seen as a control framework that manages all characteristics of ANs, provides abstraction of the resources and enables the service delivery for ANs.
A service interface, the Ambient Service Interface (ASI) has been defined as an “upper layer” interface of the ACS that is accessible to applications to define their requirements and specify how the service should be delivered (in terms of QoS, security, connectivity). The management of this request is performed by the Overlay Management (OM) FE . The OM FE will then create and maintain a service-specific overlay network to fulfill the service provider requirements and to manage the service delivery to end-users while adapting to user and network context. This specific overlay is called a Service-aware Adaptive Transport Overlay (SATO) network. The Service Context (SC) FE  is also very important in this work since the SATO should adapt automatically to context.
Figure 6: The ACS, OM FE and SATO
4. MULTI-RADIO ARCHITECTURE IN AMBIENT NETWORKS
This section gives an overview of the part of the Ambient Control Space that is closest to the radio interface: the multiradio access (MRA). More thorough descriptions can be found in .
Plenty of prior work exists on multi-radio access topics, including IP mobility schemes for handover , joint radio resource management mechanisms , and different radio abstraction layers . However, this work has only tackled partial issues, e.g., focusing on a limited number of specific RAs that could be tightly integrated, or proposing loose integration to handle many RAs but with limited support for joint resource management. The aim for the Ambient Networks MRA is an all-encompassing, flexible architecture considering all existing and future radio access technologies, and supporting different levels of coordination depending on operational modes and
business relationships so that cooperation at the radio access level is possible even between competing actors.
The MRA architecture consists of two main components: Multi-Radio Resource Management (MRRM) for joint management of radio resources and load sharing between the different RAs; and Generic Link Layer (GLL), which provides a toolbox for unified link layer processing, offering a unified interface towards higher layers and an adaptation to the underlying radio access technologies.
A main feature of the MRA architecture is resource sharing and dynamic agreements between ANs, including different access providers, through composition. Other features are efficient advertising, discovery and selection of RAs, including the possibility for a user to simultaneously communicate over multiple RAs, in parallel or sequentially, and efficient link layer context transfers. Further, the MRA architecture supports multi-radio multi-hop communication using both moving and fixed relays. The MRA architecture uses the ACS infrastructure for communication between MRA components, consistent data storage by registries and conflict resolution.
4.1 MRA ARCHITECTURE
A high-level view of the proposed MRA architecture is illustrated in Figure 7, showing functional blocks in a layered model, including user plane data flow and MRA signaling through the layers. Black arrows indicate control interfaces between different functional blocks, carrying information exchange and control commands e.g. for configuration or for measurement data retrieval. Note that only one communication peer (network or terminal) is depicted.
Figure 7: High-level MRA functional layer architecture.
The GLL is introduced on top of, and is partly replacing, the RA specific parts of L2. The toolbox of link layer functions within GLL provides a unified interface towards upper layers (IP and above) in the user plane and provides adaptation towards the underlying (remaining RAT specific) link layers.
The MRRM functions are built upon, or mapped onto the network intrinsic RRM functions, which belong to the underlying RA and are therefore not within the explicit scope of the AN MRA. The Figure 8 further illustrates the information exchange between MRRM, GLL and other ACS functions, here exemplified by mobility control and connectivity control.
The model suggests a functional split between MRRM and GLL. In general, GLL encompasses functions that are located close to the user plane of a data flow and/or need to operate on a relatively fine time scale. One example is selection of RAs for which a hierarchical distribution of functionality between MRRM and GLL is proposed, where GLL dynamically (fine time scale) handles the mapping of data flows to any of the RAs selected by MRRM (coarse time scale). Another example is that the GLL provides and reuses context information that is transferred between GLL entities at RA reselection for seamless access switching. MRRM performs spectrum and load management, and it coordinates decisions on different associated flows, where MRRM operations can be triggered either by system level operations or directly by flow level events, e.g., mobility. MRRM also establishes and maintains RAs that are possibly constituted of parallel multi-hop routes.
5. MOBILITY DIMENSIONS
Before describing the triggering architecture, we introduce the notion of mobility for which the triggers have been
Investigated. Instead of considering mobility only as a physical movement or as a change of network point of attachment, we have taken a fundamentally broader view. In Ambient Networks, mobility may take place in different dimensions, which are independent of each other. However, mobility may often take place in several dimensions simultaneously, even in a coupled manner. We have identified seven dimensions, which can be considered as orthogonal to each other. Figure 2 illustrates examples in four of these dimensions.
1) Physical location: A mobile entity1 moves between access points within the same radio access technology
2) Access technology: A mobile entity moves from one radio access technology to another (e.g. vertical handover),
3) Address space: A mobile entity moves between networks/devices, which use different address space
(e.g. IPv4 , IPv6, public and private),
4) Security domain: A mobile entity moves between networks/devices/environments, in which trust or
security are enforced differently (e.g. public secured Virtual Private Network),
5) Provider domain: A mobile entity moves between networks/devices operated/owned by a different
Provider (e.g. roaming),
6) Device properties: A mobile entity moves from one device to another, hence the system properties of the
host device may change dramatically (e.g. inter-device handover),
7) Time: A mobile entity does not move spatially, but ongoing communication is suspended for a while and
resumed afterwards (e.g. if a user wants to pause the connection for a while, or to allow a temporary loss of
Some of the triggering events relate only to a single mobility dimension, while others may require mobility actions
to be performed in several dimensions. In this high level view, a mobile entity always has a “coordinate” in each dimension. Whenever movement in a certain dimension takes place, the respective coordinate changes. Mobility management mechanisms can be seen as functions updating one or more of these coordinates.
Figure 8: Possible sources of mobility triggers.
Figure 9: Mobility may take place in various dimensions orthogonal to each
6. OVERALL TRIGGERING ARCHITECTURE
In ANs context, the triggering architecture has two main tasks:
- Collecting and transporting triggers from various sources,
- Arbitration of conflicting triggers to result in a possible handover decision and/or routing group formation. The
Trigger processing entity shown in Figure 10 is implemented in the Ambient Control Space (ACS), partly in the Triggering Functional Area (later referred to as Triggering FA or TRG FA), partly in the Handover Management Functional Area (later referred to as HO FA). Both are depicted in Figure 10. This figure also shows how ACS offers communication to external functions via three interfaces:
- Ambient Service Interface (ASI) interfaces towards service infrastructures and allows applications and services to issue requests to the ACS.
- Ambient Resource Interface (ARI) provides control mechanisms ACS can use to manage the resources
residing in the connectivity plane.
- Ambient Networks Interface (ANI) is a horizontal interface interconnecting different ACS.
Figure 10: Triggering Architecture
Triggering FA handles triggers originating from other Functional Areas (such as the Context Coordination FA,
Which collects contextual information), and other sources (such as the mobility protocol states and link-layer
Information). The HO FA, in turn, uses the collected triggers and rules stored in the policy database to resolve whether a handover is needed and which mechanisms to use, after which it proceeds to actual handover execution. Another identified user of the triggering information is the Routing Group Management FA, but further discussion on routing group management is out of the scope of this paper.
7. COLLECTION OF TRIGGERING EVENTS
Triggers for handovers are handled in three main ACS functions (see Figure 11), which are the Triggering Events
Collection (TEC), Triggering Events Classification Engine (TECE) and the Handover Decision Engine (HDE), which is described in more detail in section VI. TEC and TECE handle the collecting, classifying and storing of incoming triggers, which HDE fetches from Triggering Events Repository (Collecting triggers also requires a temporary storage, the TER, for the received triggers) for further processing. HDE solves possible conflicts between the triggers and makes decisions on handovers. It signals the Handover Execution (HE) function, which performs the actual handover. When receiving a trigger, the trigger processing classifies and timestamps the trigger. Triggers also have a lifetime, after which they are removed from the TER. The repository is more like a buffer than a database, as new triggers may be received at any time, even before the previous one has been processed.
The trigger collection process has to gather locally generated triggering events from the mobility control space (MCS). These triggers include e.g. those generated by mobility protocols (router advertisements, etc). This makes necessary that the Triggering FA has to coordinate and develop mechanisms in conjunction with other FAs within the MCS to compile triggers that could be relevant for the HO decision process. In addition, the collection process has to request (or receive) to (from) the Context Coordination FA (Concord FA) the necessary mobility context information to perform the decision that will lead to realize optimum handover operations.
Figure 11:Triggering Functional Area.
For the handover decision process, not only policies or mobility related context information should be taken into
consideration, but also context information that does not belong to the mobility control space. This type of information that we regard as “pure” context information, such as a neighboring device capabilities or geographical location is extremely useful for deciding whether to perform a handover.
In addition to gathering the triggers, the triggering events collection function need to define a relative timestamp and lifetime for the triggers. This will ensure that the gathered triggers are used in correct order for rules evaluation and are still valid in the appropriate context situation.
The gathering of triggering events requires the definition of interfaces between the involved FAs. However, depending on the type of the trigger and its importance to attain the goal of seamless handover, there could be a combined implementation to gather triggers.
A basic set of rules for gathering the triggers for performing HO decision could be defined as the following:
- There are some types of mobility triggers that need to be acted upon immediately (real-time) in order to
Perform a smooth handover operation.
- If the trigger is a real-time class trigger, it can be collected directly from source (FA)
- There are other types of mobility triggers which are not time sensitive (non real-time) that could be gathered periodically or on demand.
- If the trigger is a non-real-time class, it may be collected from Concord FA
- Policies and Agreements that could be considered as triggers could be gathered first at call/session setup
- Other non-mobility context triggers would be collected from the Concord FA.
8. TRAFFIC ENGINEERING
For a network operator it is important to analyze and tune the performance of the network in order to make the best use of it. The process of performance evaluation and optimization of operational IP-networks is often referred to as traffic engineering. One of the major objectives is to avoid congestion by controlling and optimizing the routing function. The traffic engineering process can be divided in three parts as illustrated in Figure 12. The first step is the collection of necessary information about network state. To be specific, the current traffic situation and network topology. The second step is the optimization calculations. And finally, the third step is the mapping from optimization to routing parameters. Current routing protocols are designed to be simple and robust rather than to optimize the resource usage. The two most common intra-domain routing protocols today are OSPF (Open Shortest Path First) and IS-IS (Intermediate System to Intermediate System). They are both link-state protocols and the routing decisions are typically based on link costs and a shortest (least-cost) path calculation. While this approach is simple, highly distributed and scalable these protocols do not consider network utilization and do not always make good use of network resources. The traffic is routed on the shortest path through the network even if the shortest path is overloaded and there exist alternative paths. With an extension to the routing protocols like equal-cost multi-path (ECMP) the traffic can be distributed over several paths but the basic problems remain. An underutilized longer path cannot be used and every equal cost path will have an equal share of load.
Figure 12: The traffic engineering process.
8.1 CLASSIFICATION TRAFFIC ENGINEERING METHODS
A classification of traffic engineering schemes is possible along numerous axis. Our framework is intended to facilitate the analysis and help us identify the requirements for traffic engineering in Ambient Networks.
- Optimize legacy routing vs. novel routing mechanisms. One approach is to optimize legacy routing protocols. The advantage is easy deployment of the traffic engineering mechanism. However, the disadvantage is the constraints imposed by legacy routing.
- Centralized vs. distributed solutions. A centralized solution is often simpler and less complex than a distributed,but is more vulnerable than a distributed solution.
- Local vs. global information. Global information of the current traffic situation enables the traffic engineering
- Mechanism to find a global optimum for the load balancing. The downside is the signaling required to collect the
- Information. In addition, in a dynamic environment, the information quickly becomes obsolete.
- Off-line vs. on-line traffic engineering. Off-line traffic engineering is intended to support the operator in the management and planning of the network. On-line traffic engineering on the other hand, reacts to a signal from the network and performs some action to remedy the problem.
The taxonomy above is intended to assist us in the analysis of traffic engineering methods in Ambient Networks and should not be regarded as complete. A detailed taxonomy of traffic engineering methods can be found in RFC 3272 .
8.2 CHALLENGES FOR TRAFFIC ENGINEERING IN AMBIENT NETWORKS
The main challenge for traffic engineering in Ambient Networks is to cope with the dynamics of both topologies
and traffic demands. Mechanisms are needed that can handle traffic load dynamics in scenarios with sudden changes
in traffic demand and dynamically distribute traffic to benefit from available resources. The different traffic engineering methods can be categorized by how much network state information they use. These ranges from methods that only use local state information to improve the load-balancing to optimization methods that need global state information in the form of link capacities and a traffic matrix as input. The trade-offs between optimality, stability and signaling overhead are crucial for traffic engineering methods in the fixed Internet and it is even more critical in a dynamic ambient environment.
The traffic engineering problem can best be modeled as a multi-commodity flow optimization problem. This type of optimization techniques take as input global information about the network state (i.e., traffic demands and link capacities) and can calculate the global optimal solution. In practice though, there might be several reasons why we need to deviate from the optimal use of the network. This could be because the calculations are too resource consuming and take too long time. It could also be because the input needed is hard to measure and collect and that it varies too much over time so it would create too much signaling overhead or create instabilities.
MCF optimization problems easily become large with tens of thousands of variables and constraints. But it is possible to calculate the global optimal solution in tens of seconds even for large networks  if no constraints are given on the number of paths that can be used. Finding the optimal set of weights in OSPF though usually has to rely on heuristic methods.
One can argue that, if it is important to make the best possible use of network resources then the routing should not be restricted to what can be achieved by tuning the weights in the legacy routing protocols. Instead, the optimization should come first and the result should be implemented using new routing mechanisms if needed. On the other hand, the study by Fortz et.al  shows that in practice the solutions that can be achieved by proper weight settings in OSPF are close to the optimal at least for the networks they investigated.
Multi-commodity flow optimization as well as heuristic methods for setting optimal weights in OSPF is both typical examples of centralized schemes that use global information in the form of topology and traffic matrix and produce global optimum routing or at least results that are good for the network as a whole. The problems with this type of solution are measuring the traffic demands that are needed as input and the signaling overhead created when collecting this data. A centralized solution also creates a possible bottleneck and a single point of failure. Further, in a dynamic environment the traffic data quickly becomes obsolete. If the routing decisions are based on the wrong input we may create congestion that would not be there if just shortest path routing had been used. This sensitivity to the traffic dynamics of course holds for all types of load-sensitive routing.
Examples of other schemes that uses global information about both the topology and the traffic situation but takes local decisions (and so avoids some of the problems with a centralized solution) is different kinds of QoS-routing schemes. Here information about for instance delay or load on each link in the network is flooded to all nodes. Each node then makes shortest-path (or least-cost) calculations in this metric. Each node chooses the best
Paths through the network from its own perspective but the decisions are all local decisions without consideration of the network as a whole. So care must be taken with this type of mechanism to avoid hot-spots where everybody moves traffic to underutilized links and route flapping were nodes constantly shift load back and forth.
Another possibility would be to only use local inform information when taking local decisions and so avoid all the signaling overhead . If we can assume that the topology is much more constant than the traffic load then we can use global information about the topology i.e using legacy protocols like OSPF to calculate the connectivity (shortest paths) and use only local information about the traffic situation to balance the load in the network. This is an interesting approach in a dynamic environment such as ambient networks, with sudden changes in traffic demand. For instance in a scenario with a moving network such as a train with an internal access network passing through an operators network. Instead of flooding the network with load information and wait for a new routing to be calculi acted a node can make local decisions and adapt to the situation. A node the at experiences a sudden increase in traffic demand can directly shift load from heavily loaded links to underutilized paths. The drawback of this is of course that the consequences of the local decisions for the network as a whole are difficult to grasp. Care must be taken so that local improvements don’t create overload somewhere else in the network. So, a careful evaluation of this type of mechanism is needed.
There are different timescales for traffic engineering. An interesting approach would be if global information reflecting the traffic situation in a coarser and longer time perspective could be used to make a tentative routing calculation for the whole network. And let the nodes fine-tune the routing parameters with respect to local information in the nodes or information gained from the immediate vicinity of respective node. But this is a topic for further study.
Network composition is a new concept for dynamic and instantaneous interworking of networks on the control plane. In this paper we aimed at giving a practical illustration of network composition. We depicted two distinct scenarios in terms of today’s technologies and highlighted were technology needs to be augmented to allow plug and play internetworking of networks. Then, we showed how both scenarios, while very different at first sight, can be described as particular instances of the same concept, network composition. Ambient Networks architecture, focusing on several key functions of the control space. The control space provides common infrastructure for message passing, conflict handling, registry and connectivity abstractions.
Specifying a distributed triggering framework includes many challenges, which are still to be addressed. Those include, for example, practical implementation of trigger classification mechanisms, scalability and performance of the trigger collection and distribution mechanisms, as well as the feasibility of the rule based handover decision logic. In future work we will enhance the conceptual model by developing the interfaces and protocols for communication between the entities in the architecture, as well as define the delivery mechanisms and format of trigger information. Feasibility analysis and tests in a real environment will follow. The framework for classification of traffic engineering methods is introduced to facilitate the analysis and identification of challenges for traffic engineering in Ambient Networks.
 EU-IST project 507134 Ambient Networks, http://www.ambientnetworks. Org
 N. Niebert, et al, “Ambient networks: architecture for communication networks beyond 3G,” IEEE Wireless Communications, vol. 11, pp. 14-
22, IEEE, April 2004.
 R. Ocampo, L. Cheng, Z. Lai, A. Galis, “ContextWare Support for Network and Service Composition and Self-adaptation”, in Proceedings of the 2nd International Workshop on Mobility Aware Technologies and Applications (MATA) 2005, Montreal, Canada, October 2005.
 L. Cheng, K. Jean, R. Ocampo, A. Galis, “Service-aware Overlay Adaptation in Ambient Networks”, International Multi-Conference on Computing in the Global Information Technology (ICCGI) 2006, Bucharest, Romania, August 1-3, 2006.
 T. Petersen, et al., “SMART – Final Architectural Design”, IST-2002- 507134-AN/WP5/D03, http://www.ambientnetworks. Org/publications/D5 3 SMART Final Architectural Design_
 V. Gupta & D. Johnston, “A Generalized Model for Link Layer Triggers”, March 2004, http://www.ieee802.org/handoff/march04_meeting_docs/Generalized_tri ggers-02.pdf (URL)
 A. Yegin, E. Njedjou, S. Veerepalli, N. Montavont, & T. Noel, “Linklayer Hints for Detecting Network Attachements”, Internet draft draftyegin- dna-l2-hints-00.txt, Oct 2003, work in progress.
 N. Niebert, A. Schieder, H. Abramowicz, G. Malmgren, J. Sachs, U. Horn, C. Prehofer and H. Karl. Ambient Networks – An Architecture for Communication Networks Beyond 3G. IEEE Wireless Communications, April 2004.
 N. Niebert, H. Flinck, R. Hancock, H. Karl and C. Prehofer. Ambient Networks – Research for Communication Networks Beyond 3G. Proc. IST Mobile Summit, June 2004
 D. D. Clark, J. Wroclawski, K. Sollins and R. Braden. Tussle in Cyberspace: Defining Tomorrow’s Internet. Proc. ACM SIGCOMM, Pittsburgh, PA, USA, August 2002.