The deliverable D-2.3.1 Final Architectural Framework is available for review and comment.
The 4WARD WP2 main objective is the development of an Architecture Framework to represent and design future network architectures within families of interoperable networks. The developed set of solutions, concepts, and procedures can be used to model current networks, 4WARD networking solutions and future networks.
This Architecture Framework comprises architectural concepts as well as a Design Process. With respect to the architectural concepts we followed a macroscopic view on network architectures as well as a microscopic view in order to develop the basic constructs of the Architecture Framework. The macroscopic view introduces the concept of Strata as a flexible way to layer the services of the network that inherently supports cross-layer information exchange. The microscopic view concentrates more on the functions needed within a network node in a certain network architecture. These functions are encapsulated in so-called Netlets. The Node Architecture provides a generic framework for Netlets. It can flexibly host Netlets, which possibly belong to different network architectures. Within the Node Architecture, Netlets are considered as black-boxes that provide a certain service and that can be exchanged on- the-fly if needed.
This document, D2.3.1, focuses on the work provided during the last six months of the project. Both deliverables together, i.e. D2.3.0 and D2.3.1 describe the Architecture Framework developed within the 4WARD project and provide evaluation results. The focus during the last six months of the project was mainly on two directions:
Complementing the Architecture Framework with a focus on the Design Process and the Design Repository
Evaluation of selected parts of the Architecture Framework
Since this deliverable concentrates on the work performed during 2010, i.e., during the last period of the project, it naturally has some focus on evaluation. Additionally, the basic constructs and concepts have been complemented with further details. Clearly, main focus was on the Design Process, especially the Design Repository and examples for Design Patterns. In the following, an overview of the complements and conclusions is given.
The strata concept (i.e., the macroscopic view) eases cross-layer information exchange, especially due to the availability of vertical strata. Additionally, it provides an increased flexibility since it avoids strictly hierarchical layering. Prototyping activities around the CBA- based prototype can be seen as a feasibility proof of the strata concept.
The Node Architecture (i.e., the microscopic view) should be seen as a framework for a network node that runs multiple network architectures concurrently. It could be shown that Netlets can be exchanged on the fly and that the selection process of a suited Netlet does not become a bottleneck. Example Netlets for end systems and intermediate nodes are presented, reflecting the advantages of the flexible composition approach. In order to support dynamic configuration of network architectures, some alternatives regarding the associated signalling and negotiation are discussed. Various demonstrators and prototype implementations have underlined the practicability of the concepts around the Node Architecture and the Netlets.
Considering the Design Process a major focus was on the Design Repository during this phase of the project. It promotes reusability and avoids that the Network Architect reinvents the wheel every time a new network architecture is being designed. It contains, for example, the basic constructs (Strata, Netlets), Design Patterns, and software components. Security aspects related to the Design Repository are discussed. The security built into the Design Repository is closely related to how it will be used.
Three Design Patterns were developed: The Interdomain Interface, the Association and Composition of Functionalities. With the Interdomain Interface, a minimal implementation of the SGP (Strata Gatewaying Point) is provided that is to be implemented at all interconnection points between domains. The Association provides support for proper modelling of a variety of communication paradigms. Furthermore, the Composition of Functionalities describes a way on how a Network Architect can compose functionalities, in addition to the application of SOA- based concepts to the composition of functionalities.
The second part of this deliverable documents the validation and implementation work in this last working period. Different methods have been applied for evaluation and validation purposes: use cases, modelling, simulation experiments, and prototyping (including demonstrators).
The Design Process has been validated through the application of a use case related to an AdHoc Community. Different types of requirements (business requirements and technical requirements) are derived as first steps, followed by the identification of network functionalities at the macroscopic level (i.e., strata) and, along with this, the logical nodes. Then Netlets are identified. In order to derive an implementation of the designed network architecture, the software components are then selected, combined and, eventually, deployed. This validation effort has underlined the general usefulness of the Design Process and its applicability. Further support by appropriate tools, however, will be needed for practical applications. The Netlet Editor developed earlier within the project can serve as a simple example for that since it provides some support for the design and evaluation of Netlets. The same holds for the Acme-based modelling activities as described in the following.
A formal model of the network architecture from a macroscopic point of view is provided in addition to a model from a microscopic point of view that has been developed earlier in the project. The modelling was done in Acme. Armani predicate rules were applied to validate the correctness of the modelled scenario. It could be shown that this way of modelling network architectures supports the Network Architect during the design of a network architecture. The validity of the scenario as well as the fulfilment of properties can be proven.
The practicability of the selected concepts of the Architecture Framework was mainly validated through prototyping activities that also resulted in different demonstrators. These demonstrators were presented at the project review in Aachen in 2010.
• Integrated WP2/WP4 demonstrator:
This demonstrator integrates concepts of In-Network Management (WP4) with basic constructs (Strata, Component-Based Architecture) of the Architecture Framework. Easy deployment of networks, real-time monitoring and self-adaptation within network domains were demonstrated. Another important issue was on the interoperability between different network domains based on the strata SGPs (Strata Gatewaying Points).
• Integrated WP2/WP3 demonstrator:
This demonstrator integrates virtual networks (WP3) with basic constructs (Node Architecture, Netlets) of the Architecture Framework. It shows the design and test of Netlets as well as the deployment of the Node Architecture (including Netlets) into a virtual network. Dynamic adaptations of Netlets as well as the virtual network were successfully demonstrated.
Both prototypes, the CBA-based prototype as well as the Node Architecture prototype, were enhanced during the last period of the project.
• The CBA-based prototype was extended with an implementation of the Association Design Pattern as well as with a sequence to elaborate on a novel name resolution and routing scheme.
The Node Architecture prototype was extended with Routing Netlets (AODV-based, OLSR-based) supporting different types of mobile ad hoc networks (MANETs) with individually suited routing services. Additionally, a protocol for dynamically switching between these Routing Netlets as reaction to changes in the networking situation has been designed and implemented. Regarding the Node Architecture it could be shown that both, fine tuning of parameters as well as dynamic switching of similar Netlets is supported. Generally, this underlines the flexibility and extensibility of the Node Architecture.
The switching protocol was tested and evaluated in a simulation environment. It could be shown that the proper parameter tuning improves the convergence time, as expected.
• The Node Architecture prototype was further extended with QoS blocks. The validity of the implementation was tested through network measurements.
Furthermore, signalling in multi-access networks has been designed and incorporated into the integrated macroscopic/microscopic view and investigated through simulation experiments.
• Two tuning/optimization algorithms have been developed to optimize the packets size for WLAN transmissions. It could be shown that throughputs with controlled packets size are significantly higher than with fixed packets sizes. The number of concurrent users in WLANs can be increased.
• The selection of the network interface within a multi-access network was also investigated. Based on the proper interface selection, delay and throughput can be improved.

The deliverable D-4.5 Evaluation of the in-network management approach is available for review and comment.
Work Package 4 (WP4) of 4WARD has worked towards the definition of novel management instruments to operate the future Internet. In-Network Management, (INM), utilizes decentralization, self- organization and autonomy as its basic enabling concepts. The idea is that, contrary to the legacy centralized approach, the management tasks are embedded in the network. The managed system now executes management functions on its own. The INM concepts and its design are detailed in 4WARD WP4 deliverables D4.2 In-Network Management Concept ] and D-4.3 In-network management design].
Deliverable D4.1 described scenarios and use cases for the Future Internet, and for each scenario, derived requirements to enable it. This deliverable compiles a comprehensive list of requirements from all the scenarios, and uses them as a basis for evaluating the INM design concepts developed by all WP4 tasks.
The evaluation process follows a WP4-adapted V-model, in which the INM implementation is checked against its testing results in a top-down approach, from the full system down to each of its components. This methodology facilitates an evaluation without the need for a comprehensive implementation of all NM functionality, a valuable feature for this clean-slate conceptual project. The evaluation effort is split into three separated topics that match the structure of the WP4 activities: framework, algorithms and a demonstrator. Depending on the extent of the implementation, different evaluation instruments are used.
The analysis utilizes two agreed templates, one for the framework and one for the algorithms. The framework is evaluated for scalability, robustness, reduced integration effort, and reduction of complexity. Each INM algorithm from tasks 4.3 and 4.4 is evaluated with the algorithm template.
Special attention was given for the evaluation of cross WP activities: INM for NewAPC (cross WP2/4), INM for VNET (cross WP3/4), INM for GPs (cross WP4/5), and INM for NetInf (cross WP4/6). The business aspects of INM (includes cross WP1/4) were also studied.
The evaluation analysis demonstrates that every requirement identified in Deliverable D4.1 was addressed by some algorithms in D4.2 ] and D-4.3 ]. The degree of coverage of each requirement varies, and explanations are given for those that are lightly addressed. Compared with legacy management systems, INM design is shown to be scalable and robust. Moreover it facilitates reduction of integration effort and reduction of complexity. Most importantly, INM is beneficial for NewAPC, VNets, GPs and NetInf, and it demonstrates business incentives that are realized with potentially reduced OPEX and increased EBITDA values.
In summary, the evaluation analysis of the simulation results shows that the INM design is beneficial for the Future Internet. The next step is to test the feasibility of INM concepts in real experimental networks.

The deliverable D-4.4 In-Network Management System Demonstrator is available for review and comment.
4WARD proposes a novel approach of network management, called In-Network Management (INM). Its basic enabling concepts are decentralization, self-organization, and autonomy. The design of key INM functions has been reported in the previous D-4.3 In-network management design.
This D4.4 document reports the results of the prototyping activity of WP4 in 4WARD. The objectives are twofold. First, it provides an analysis of potential exploitation scenarios of INM in the future Internet. Second, it reports the experience of an integrated implementation of the INM algorithms and provides a refinement of the INM design with detailed information flows.
Three scenarios have been identified as results of the joint activities between WP4 and the other Workpackages in 4WARD. The first scenario is about dynamic deployment of connectivity in emergency situations, where the interoperability function of WP2 is integrated with the INM real-time monitoring. The second scenario considers integration of INM cross- layer metrics with adaption function of the Generic Path considered in WP5: network coding is considered in our implementation as adaptation function. The third scenario applies INM function to virtual networks as considered in WP3. Here INM objectives are used to configure adaptive actions in case of congestion and therefore support operators’ business models. The document briefly discusses the benefits of the INM approach in these discussions, which can be summarized in three major items: reduction of integration effort, simplification of management operations and support for operator’s business.
The scenarios have implemented through a selected set of INM functions. To offer a unified view of the operations in INM, we describe first the organisation interface and we show then its configuration for objectives as well as controlling properties of the INM algorithms. This interface allows also for composition of INM algorithms and construction of workflows at local level (e.g. anomaly detection and triggering of adaptation function) and at domain level (e.g. construction of aggregated key performance indicators).
As experience of our implementation work, we provide details about specific INM algorithms: INM Runtime, Clustering, Anomaly Detection, Monitoring, cross-layer QoS. For these algorithms we describe a decomposition into functional modules and interaction diagrams. These instruments show how the functions designed can be implemented and mapped to the message flow in accordance to the INM interfaces.
This deliverable is one of the two final deliverables of WP4 and is complementary to D-4.5, which reports evaluation studies.