The Ambient Networks project
The Ambient Networks project aims to create an innovative, industrially exploitable new internetworking framework vision based on the dynamic composition of networks. It aspires to realize a clean redesign of existing architectures, based on its architectural principles and requirements shown in this chapter. The resulting system will provide access to any network, including mobile personal networks, through instant establishment of inter-network agreements.
This chapter highlights the main features of the Ambient Network project, illustrating its definitions, goals, architectural principles and innovative ideas.
2.1. Overview
The project adopts the design paradigm of horizontally structured mobile systems that offers common control functions to a wide range of different applications and air interface technologies. Such a radical change requires the definition of new interfaces and a multitude of standards in key areas of future media- and context-aware, multi-domain mobile networks.
To define an affordable and scalable mobile communication network, that opens up new ways to communicate, for billions of people and devices.
To facilitate "ambient networking", allowing to increase competition and cooperation, enabling efficient use of resources in an environment populated by a multitude of devices, technologies and business actors. To achieve a broad industry consensus on ambient networking,
creating new business opportunities for mobile network service provisioning.
To develop a solution that provides easy to use, rich, and trustworthy multimedia communication services for all.
2.2. Definitions
The basic definition [1] to understand the Ambient Network project are: Ambient Network: an Ambient Network (AN) is a set of one or more
nodes and/or devices, which share a common control plane called the
Ambient Control Space. Well-defined access to the Ambient Control
Space is provided to users or other Ambient Networks through external interfaces, in particular the Ambient Network Interface for horizontal interaction and the Ambient Service Interface and Ambient
Resource Interface for vertical interaction. An Ambient Network has
one or more globally unique identities by which it can be contacted, and it may be able to compose with other Ambient Networks.
Ambient Control Space (ACS): a set of all control-layer representations and functions of resources in an AN. They are
organised into various Functional Areas, along with the necessary functionality to ensure that the individual decisions of each Functional Area (FA) are consistent with each other and that conflicts between contradictory decisions are resolved.
Ambient Network Service Agreement: an agreement on usage of "resources" (access, connectivity etc.) between ANs and possibly compensation for the usage. The agreement may be symmetric (e.g. sharing of each others resources) or asymmetric (e.g. use of resource in exchange for payment).
Functional Area (FA) is a concept to group functions into topic-related sets for easier reference and discussion.
2.3. Architecture
Any activity that determines the scope and applicability of the Ambient Networks project needs a high-level architectural foundation, for two main goals:
To provide a coherent framework within which the detailed work of the project can be integrated. The complexity considered in the scope of Ambient Networks is so great that it cannot be designed as a single monolithic, integrated control function. Instead, some looser and more abstract system concept is required, within which individual control functions can cooperate.
To provide a consistent framework within which the interaction with external networks or the long-term evolution from existing networks can be analysed and understood. The implication of this goal is that the
architecture should be applicable across a very wide range of networking environments and over very long timescales.
There are many different styles of network architecture, ranging from the abstract to the detailed. The original Internet architecture is an example of the former: it consists mainly of a set of general principles (such as ‘Internet Transparency’) and leaves all issues of logical and physical topology and distribution of functionality as matters of implementation and deployment. In contrast, cellular network architectures, which are more targeted at a specific set of deployment scenarios, are typically much more detailed at least at the functional level.
The level of detail of Ambient Networks architecture is somewhere between these extremes. It describes and it manages the interaction between different control functions, but on the other hand, it limits any assumptions about functional or physical topology to those that are necessary to make progress, even if additional assumptions would seem harmless in today’s environments.
2.3.1. Architectural Design Principles
The set of principles adopted to guide the design has been developed out of the experience with previous network architectures, and these can be used to select between different design options.
2.3.1.1. Simplicity
The most important principle is the simplicity at the architectural level. Simplicity has a number of benefits, directly related to our overall goals:
It increases the applicability of the architecture to different types of network.
It makes it easier to relate to existing networks.
A simple architecture is easier to evolve: complex architectures often impose artificial distinctions between different elements and evolution often needs to blur these distinctions.
Simplicity does not force us towards a network with limited functionality; rather, it implies that sophisticated functions should be localised to a particular component within the architecture, avoiding far-reaching interactions.
Simplicity as a design principle directly influences the types of entity and interface that should be considered: the number of these ones should be minimised. This is the motivation behind basing the architecture on only a single type of networking entity, the Ambient Network, which therefore has only a single (inter-network) reference point (the Ambient Network Interface) and a small set of service interfaces.
2.3.1.2. Openness and Extensibility
The second major principle is that of demanding that functionality should be made visible in an open and extensible way. Many networks have been designed to provide sophisticated control functionality, but no common or well-understood way for users of the network to discover or exploit these functions. The design principle of openness requires that appropriate interfaces need to be provided to exploit the functions that are being implemented. So much of the Ambient Networks concept is based on the building of complex inter-networks from simpler Ambient Network components.
A second, related principle is that it is more important to achieve a minimal basis on which more sophisticated functions can be built, than to design something which is very complete in its capabilities, but whose complexity presents an insuperable barrier to deployment. Two specific design principles that support this general goal are:
Separation of transport and control: this allows these two functions to evolve independently, which is particularly important if one function has to be deeply integrated with hardware (e.g. link layer) implementations, and the other needs to evolve to support more upper-layer related requirements.
Concentration of intelligence at the edge of the network: this allows additional functionality to be bolted on to the network close to the user without affecting the core. Note that this is not equivalent to assuming all intelligence is in the end systems themselves, because there may be regulatory or policy issues that give a special role to ‘first hop’ network providers. However, it is assumed the notion that the placement of functionality should be flexible.
2.3.1.3. Heterogeneity and Implementation Hiding
Some network architectures have been based on the assumption of a single service model (for example, for Quality of Service definition) across an entire inter-network. Although this provides for an ideal degree of simplicity (minimising negotiation and the need to support functional variants), it is clear that it also presents a major barrier to deployment and especially inter-working with existing networks, which may not have the same model as Ambient Networks.
Therefore, the Ambient Network project attempts to minimise the required
level of homogeneity across Ambient Network boundaries. This can be seen
as a specialisation of the simplicity principle, applying it to the interface (reference point) between Ambient Networks.
2.3.1.4. Scalability
Scalability has to be considered with respect to many different dimensions, such as network size, number of terminals, number of operators, level of mobility or traffic volume.
More precisely, the scalability of a network system is a measure of its ability to maintain efficiency in a set of metrics, with respect to a given environment if an independent parameter of the network increases to a very large value. These parameters can be classified as follows:
"Independent parameters" are parameters that can be freely varied, such as number of mobile nodes, node density, traffic load, or mobility behaviour.
"Primary metrics" are performance quantities that are observed in the network, such as throughput, delay and battery power.
"Environmental parameters" are parameters that define the operational conditions of the network. Many environmental parameters may affect scalability, including network characteristics, node characteristics, or mobility patterns being used.
The Ambient Network design considers scalability with respect to the above major parameters such as network size or number of mobiles.
2.3.1.5. Compatibility and Migration Strategies
Although backwards compatibility and migration are requirements, there are a number of design guidelines and principles, which may aid implementation of these requirements. Even if migration from current technologies and compatibility is different, similar approaches that address these issues exist. Note that compatibility can enable smooth migration. The Ambient Network project aims for a design that includes existing technology in one of the following ways:
Encapsulation of existing functionality to be used to hide this functionality and use it in a different context with potentially different interfaces.
Enhance the functionality to make it compatible and interoperable with new networking functionality.
Interoperate with existing technologies using their original interfaces. This means to extend the new technology by additional interface adaptors that enable the interoperation.
2.3.1.6. Design for Wireless Devices
er important design guideline is focus
Anoth ed on wireless devices when
de r lower-layer functionality, it is also
concern for higher layers and the control plane, which also should fining the system. Although obvious fo
a
seamlessly integrate with non-wireless infrastructure. In particular, the problems we address are:
Limited battery and computation power in mobile devices. Limited, intermitted communication of wireless links.
The main point is to consider intermitted communication as a basic principle
of t ces may be
a l ctions between
etwork Composition is a new architectural concept introduced in Ambient Networks to
position thus goes beyond what the Internet ne work design. While the limited capabilities of wireless devi
sca ability issue, this influences the distribution of fun
network and wireless devices. This has to be guided through awareness of the limited resources of many devices.
2.3.1.7. Network Composition
N
enable plug&play control-plane interworking, as well as sharing of control among networks. Com
and the mobile networks can provide today, where control-plane interworking, e.g. roaming agreements, need to be negotiated and realized manually. Furthermore, Composition covers the actual sharing of control if so desired: e.g. a WLAN operator may decide to give up authentication and charging control and hand it over to the operator of a UMTS network. While this functionality is already available today, with Composition it can be
extended to cover more control functions, becomes plug&play and hence more easy to configure (without or with minimal human interaction). Besides, Composition is an adjustable operation (its behaviour may be configured also based on user preferences), scalable (it can be used between single devices or between large networks) and extendable (it can be easily extended to include new types of control functions).
2.3.2. Specification of the Ambient Networks and the
Ambient Network Interfaces
The Ambient Networks project is working towards the specification of
Ambien traditional
lecommunications networks by a couple of features, which have been t Networks, which are supposed to differ from
te
captured in the definition of the term AN (see section 2.2). According to this definition, a traditional network or just a single communication node is turned into an AN by adding the ACS to it, where the ACS is a collection of control plane functions, which the AN project is specifying.
The work to identify these control functions goes on in the various research areas, identified by the project as follows:
Media Delivery: the functions gathered in this functional area are
een media sources and media
support for different media formats. This knowledge will be used in concerned about the establishment of end-to-end delivery chains, carrying multimedia content betw
consumers. It has been assumed that the control space functions are aware of the specifics of the transported media streams, as well as they know the capabilities, which the end user devices have regarding the
conjunction with information about the user preferences, as well as network and link state, to derive the most appropriate route between media source and sink.
Domain Management: this FA comprises all control functions organising the management of ANs.
A results into functions included into all FAs.
Security: the security F
across ANs. ANs may in addition implement mobility management functions to allow for
Mobility: the ACS functions related to mobility are supposed to
enable flow, user and node/device mobility
different kinds of mobility within a single AN.
Connectivity Control: this FA is split into three sub-areas: the Composition Functional Area, the QoS Functional Area and the Congestion Control Functional Area.
unctions necessary to
ontrol decisions is a central
Context Provisioning: this FA includes all f
collect, store and disseminate network context information. The Ambient networks project assumes that the exploitation of network context information as basis for c
component of future networks. It has thus been decided to specify an open and generic system that provides context information to functions inside and outside the ACS rather than having all FAs working on specific methods to derive required network information.
the focus of
Multi-Access: the Multi-Access FA gathers all functions necessary to
organize the parallel usage of different link-layer technologies within a single AN or between ANs which cooperate closely. Especially radio links and the functions necessary to control them are in
Radio Resource Management (MRRM-FA) and the Generic Link Layer (GLL-FA).
phical representation of the above list of FAs can be found in Figure here the ACS is depicted as surrounding “Ambient Connectivity”, is a synonym for
A gra 10, w
which any basic user plane data transfer infrastructure,
ce Interface (ASI), the Ambient Networks Interface (ANI)
possibly including legacy control functionality. The control space is depicted as embracing connectivity and it should not be understood as being a control layer residing in a well-defined protocol layer, but as a collection of functions that will have various contacts to peers in the connectivity infrastructure.
0Figure 10 includes also a second aspect of the ACS: its interfaces. The ACS offers communication to external functions via three different interfaces: the
Ambient Servi
and the Ambient Resource Interface (ARI).
The ASI interfaces towards service infrastructures and allows applications/services to issue requests to the Ambient Control Space concerning the establishment, maintenance, and termination of end-to-end connection between functional instances connecting to the ASI. The ARI offers control mechanisms that the ACS can use to manage
the resources (e.g.: routers, switches, but also media trans-coders, filters and proxies) residing in the “Ambient Connectivity”
The ANI interconnects different ACSs and facilitates the exchange of control messages to agree on service usage between ANs and the establishment of a true end-to-end control chain.
Domain Management Ambient Network Interface Mobility Multiaccess Ambient Service Interface Media Delivery Context Provisioning Security Ambient Connectivity Connectivity Controller Ambient Network Interface Domain Management Ambient Network Interface Mobility Multiaccess Ambient Service Interface Media Delivery Context Provisioning Security Ambient Connectivity Connectivity Controller Ambient Network Interface
ASI
ANI
ARI
Ambient Resource Interface Domain Management Ambient Network Interface Mobility Multiaccess Ambient Service Interface Media Delivery Context Provisioning Security Ambient Connectivity Connectivity Controller Ambient Network Interface Domain Management Ambient Network Interface Mobility Multiaccess Ambient Service Interface Media Delivery Context Provisioning Security Ambient Connectivity Connectivity Controller Ambient Network InterfaceASI
ANI
ARI
Ambient Resource InterfaceFigure 10: The Ambient Control Space.
The network resources control takes place via the ARI. The ACS can not
have to include the connectivity functions
s not present before in the networks/node, to the infrastructure.
assume the resources in the connectivity plane to all exposed interfaces as required, because the ACS is supposed to extend existing infrastructure. To overcome this situation, the control space functions operate on an abstraction of the connectivity plane rather than being aware of the exact implementation and distribution of connectivity functions. The ACS functions can thus be specified without requiring to consider these details, but instead abstraction functions have to be provided in order to translate the specific implementations found in the existing networks into the abstracted view the control space function operate on.
The abstraction functions not only
residing in the user-plane, but also control functions that are already implemented in the connectivity and should not be replaced by the ACS functions. It occurs to distinguish two different cases:
2. The ACS adds a wrapper to existing control functionality in order to make these functions interoperate with functions in other networks. In
These depicte
this case the control space is not empowered to make decisions, but only used to harmonize different approaches in order to obtain the same functionality.
considerations about the Ambient Networks logical architecture are d in Figure 11.
Service Support Layer
Mobility Connectivity Controller Media Delivery Multi-Access ASI ANI Control Plane User Plane
Legacy
ACS
ARIAbstraction of the legacy Control and User plane
Other ANs
AN
Service Support Layer
Mobility Connectivity Controller Media Delivery Multi-Access ASI ANI Control Plane User Plane
Legacy
ACS
ARIAbstraction of the legacy Control and User plane
Other ANs
AN
Figure 11: The ACS interfacing control and user plane functions in existing network infrastructure
It’s easy to foresee networks built and designed in the future with knowledge bout the ACS functions. These networks can rely more strongly on the a
presence of the ACS control functions and integrate them more closely. The connectivity functions will in this case also be constructed to better correspond to the connectivity abstractions provided by the ACS.
Figure 12 depicts a scenario in which the ACS holds all control functions of the formed Ambient Network (in this case no major control functions resides outside the ACS).
Abstraction of the native Transmission plane
User Plane
ANI-u
Native
Service Support Layer
Mobility Connectivity Controller Media Delivery Multi-Access ASI ANI ARI
ACS
AN
Abstraction of the native Transmission plane
User Plane
ANI-u ANI-u
Native
Service Support Layer
Mobility Connectivity Controller Media Delivery Multi-Access ASI
2.3.2.1. A Single-Node Ambient Network
The y treating all communication
evices as ANs of different size and complexity. Terminals, however, play a
ANI
ARI
ACS
AN
Figure 12: The ACS interfacing a user plane, which has been designed to fit the abstracted view of the user plane maintained in the control space.
Ambient Networks project aims at uniforml d
special role due to limited resources and high mobility. Still, they support the ACS and its various interfaces and there is no conceptual difference compared to larger, multi-node networks. The ACS functions of single-node ANs are not distributed and their ARI as well as ASI are node-internal interfaces. The ANI for a single-node AN stays external and enables the single node AN to use the service provided by other ANs. In the case of a user terminal, this also includes attachment to an access network.
2.3.2.2.The Ambient Network Interface (ANI)
The . It is subdivided into
everal parts that each cover the signalling needs of specific FAs (see Figure
ions in the ACS are modified or new ANI is the interface connecting different ANs
s
13). Additionally, the ANI could include a generic part, which ensures, for example, discovery of supported control function signalling protocols as well as supported versions and preferences.
Similar to the structure of the ACS, the ANI will thus be modular and new protocols can be added whenever funct
ones are added.
Figure 13: The structure of the ANI.
Abstraction A bstraction Function 5 Function 3 Function 6 Function 1 Function 2 Function 4 Function 7 Function 5 Function 3 Function 6 Function 1 Function 2 Function 4 Function 7 ANI U ser data ASI ARI ARI Am bient C onnectivity Am bient Connectivity ACS ACS AN AN Abstraction A bstraction Function 5 Function 3 Function 6 Function 1 Function 2 Function 4 Function 7 Function 5 Function 3 Function 6 Function 1 Function 2 Function 4 Function 7 ANI U ser data ASI AN ACS ACS AN ARI ARI Am bient C onnectivity Am bient Connectivity
2.3.2.3. The Ambient Service Interface (ASI)
Th It is accessible from any
ntity (e.g. end-user applications, management application, or control e ASI is the "upper-layer" interface to the ACS.
e
applications) outside the ACS, assuming the necessary access permissions. The ASI comprises two parts:
The subset of interfaces (function calls) offered by the FA of the ACS ance: these allow external entities to interact that are of external relev
with the ACS (e.g. for a content provider to setup a media distribution service or for end-users to signal context updates such as resource availability or terminal properties). See Figure 14.
ted versions and
The A
user of the ASI does not need to know the individual FA and the boundaries
2.3.2.4. The Ambient Resource Interface (ARI)
The Am side an
mbient Network between the ACS and the Ambient Connectivity as shown in Figure 14.
A generic part, similar to the ANI, to ensure the discovery of available interfaces and functions, as well as suppor
preferences.
SI abstracts the internal structure of the ACS and the FAs, thus the
between them. From an ASI perspective, the structuring of an ACS into FAs is therefore only an internal issue to the ACS and is left to the implementation.
bient Resource Interface (ARI) is an interface located in A
The ARI offers control mechanisms that the ACS can use to manage the resources residing in the “Ambient Connectivity”. These resources can be:
Routers and/or switches Radio Resources
QoS Enforcement Points, Admission Control Media Gateways
Conference Bridges Firewalls, Filters
Announcement Machines Legal Interception Devices
Figure 14: Example showing where the ARI can be used in an end-to-end session.
Figure 14 shows an example end-to-end session involving different devices and network elements. In this example, possible locations of the ARI are shown. However, there are also many cases where there is no need for the use of network resources and thus the ARI is not used. Over the ARI, different information elements are exchanged, for example: type of resources, requested QoS, etc.
