2.2.1 Rationale and Vision

As much as it may be perceived a sign of the times, the current profound interest in the visionary concept of autonomic computing (AC) appears to be primarily attributable to the related advancement in networked system design (Wódczak, 2014). Even though there is no denying that the natural drive for automation had been followed well before the conception of autonomic computing per se, it also transpires that the very foundations laid with the emergence of the same opened a completely new era in the development of its networking-related counterpart (Wódczak, 2012). Most obviously, this phenomenon is rooted in the rapid progression of unprecedentedly complex distributed systems featuring a multitude of interconnected appliances, each overseen by sophisticated software and, thus, altogether posing a critical demand in terms of being properly configured and maintained with, virtually, no delay. In order to provide an exhaustive explanation in this respect, it is necessary to investigate the non-technical, biological origins of autonomics, and to analyse its business-orientated and technologically varying enablers. In this way one may not only be able to discern the technological shift, but also obtain a much better insight into the relevant convergence-driven and hardware-based similarities between computing and networking in general. Yet, no sooner may the entire picture become more complete than the prevailing role of software has been disguised in the sense that it is not only responsible for the overseeing of its underlaying hardware, but especially accountable for the orchestration of its own routines (Wódczak, 2014).

Looking from the intrinsic perspective, as indicated by Kephart and Chess (2003), the origins of the idea behind legacy autonomic computing are undoubtedly profoundly rooted in inspiration drawn from the functioning of the human autonomic nervous system (HANS),¹ naturally intended to orchestrate the behaviour of the internal organs through the monitoring of numerous related parameters, such as heart rate or body temperature, for the sake of releasing the brain itself from controlling them in a fully aware manner. This appears to be the key point as to the explanation of the actual rationale behind autonomics, especially given the fact that, even though there is an abundance of such parameters that are considered to be crucial for the uninterrupted functioning of a human organism, the said process of orchestration is carried out in a somewhat detached, if not distributed, fashion, as explained by Paulson (2002). For this reason, the structure of such an autonomic system (AS) is said to resemble a recursively arranged hierarchy, where each of the numerous entities that display the capability of self-management at a given level of abstraction (LoA) should encompass the similarly numerous and conceptually alike, yet functionally varying, components one level below, and so forth, as advocated by Kephart and Chess (2003). Attempting to apply a more descriptive terminology, one could equally well approximate the above-mentioned conceptual construction by instantiating it with a rather generic pattern, where the structure itself would originate from the lowest molecular level, just to move forward through human markets and societies, in order to approach the top level of world's global socio-economy (Kephart and Chess, 2003).

Yet, assuming a more extrinsic viewpoint, it seems that the business model has undergone so substantial a change, over little more than a decade, that it became the major enabling factor in the said respect. In fact, originally, the objective of autonomics² was to address large commercial computer systems, clearly bringing the connotation of and indicating an institutional or corporate context, where the key interested parties could be identified as network or system administrators, without any specific participation of the end users. However, as it is to be demonstrated throughout the remainder of this book, the most recently observable progress in the field of autonomics tends to result from a shift of the previously so popular in-house computing, based on business applications, more towards the use of ubiquitously mobile and interconnected consumer devices, thereby replacing the former business-to-business (B2B) model with one that is more business-to-customer (B2C) orientated. At the same time, the major technological stress is still being placed on network providers forming, in many cases, a kind of a mediation layer between the customers, chiefly understood as the end users, and the service providers, who are frequently the network operators themselves. This way a business-driven market demand has arisen with the intention of advancing the technological and architectural entities of relevance so that a synergetic and convergent approach could materialise, where the realms of both autonomic computing and autonomic networking (AN) become welded very tightly together, as indicated by Wódczak (2014).

In the light of the above-mentioned non-technical origins and technologically variable enablers of autonomics, one may conclude that the reason for its emergence might be highly correlated with the question of the continually increasing complexity of computer systems (Wódczak, 2014). In fact, such an observation brings the immediate connotation of the related demand for timely operation and proper maintenance, which, following Paulson (2002), may be directly translated into the application of certain self-monitoring and self-recovery techniques in order to ensure the ability of the system to function in a fully sustainable manner, without reliance on human-driven intervention, at least over the majority of the time of observation. A reverse analysis of the subsequent stages of the development of autonomics might seem to trace the origins of its concept to the famous manifesto referred to by Kephart and Chess (2003). In particular, scrutinising the related works towards this direction, one might eventually come across a fairly repeatedly used notion of the said self-healing applied not with regard to computer systems, as perceived from the macroscopic perspective, but rather embedded into the microscopic picture of a central processing unit (CPU). Interestingly, as depicted in Figure 2.1, this leads to the conclusion that, initially, the term ‘autonomics’ might have been semantically capacious enough to encompass even concepts such as redundant microprocessor modules (Paulson, 2002). While this understanding could still hold today, it appears that currently the macroscopic context prevails more conspicuously.

Nonetheless, the presented notions should by no means be understood as contradictory, but, quite the opposite, rather perceived in an evolutionary way since the primary and mirror units visible in Figure 2.1 already form a kind of a connected setup very much resembling the rationale behind a networked system, especially because of the fact that the intermediary parity check and recovery units appear to be responsible for establishing a relevant communication and data exchange protocol between the interconnected elements. What is more, following Paulson (2002), it may similarly be claimed that such hardware introduces intelligence,³ expected to be accompanied by relevantly smart applications, which brings up the very practical question of assuring the most appropriate composition of an autonomic networked system design in terms of both the deployed software and hardware. This, in turn, extends to the very rationale behind and the vision ahead of autonomics, as in the case of designing a fully-fledged autonomic networked setup one would need to accommodate the necessity for embedding not only a self-managing operating system and software, but also redundant memory and processors featuring self-healing firmware (Paulson, 2002). Most importantly, however, one should note that the value of software becomes critically important even in the case of networked systems, as otherwise autonomics could be mistakenly perceived as being realised with hardware redundancy only, while, in general, it would be primarily expected to manifest itself through accurate software self-management, where network layer protocols could be encompassed accordingly, just to follow Wódczak (2014).

As much as this perception might be a conceptual enabler of a proper positioning of the role of such software for the sake of autonomic system balancing, especially in the field of distributed computing, it is crucial to keep in mind that, in fact, nowadays software has already become so ubiquitous that it could be equally well named a regular commodity of a highly complex nature. This way, the autonomic flavour of such software appears to be twofold: on the one hand, its role is to maintain the proper operation of the underlying networked system; on the other hand, it needs to be able to sustain its own operation, which might make both aspects equally challenging, mostly for complexity reasons. This holds true especially for critical systems where any potential failure may bring catastrophic consequences, primarily, but not always, in financial terms. As pointed out by Hinchey and Sterritt (2006), the mitigation of such effects may cause an organisation to come under pressure to spend as much as 33 to 50 per cent of the total cost of ownership (TCO) of the computing and communications infrastructure for the sake of avoiding any unintended or unexpected system malfunction due to software failure. It therefore became highly desirable to find a holistic approach at the overall system level that would be of value in such cases and, as a result, the idea of self-managing software was proposed to handle self-direction, self-governance, and self-adaptation (Hinchey and Sterritt, 2006). Clearly, such an approach is tightly bound with self-managing hardware, where the above-mentioned principles of complexity hold both at the microscopic and macroscopic levels (Wódczak, 2014).

Thus, the concept of autonomics should be chiefly understood as an arrangement of networked devices, altogether taking the form of a widely distributed setup, where the notion of self-management interweaves the aforementioned software- and hardware-related aspects. Following Brazier et al. (2009), and assuming a more systematic perspective, one may enumerate the following three major enablers of autonomic system design. In the first place, the enabling role of the complexity of an autonomic networked computing system (ANCS) is considered, with the emphasis on topics such as highly demanding and advanced routines for database management, characterised by the nontriviality of orchestrating numerous parameters of high significance. Next, the commercial roll-out and widespread deployment of service-oriented architecture (SOA) increases the complexity of the setup even further, adding yet another dimension to the above-mentioned issue, since the distribution of the pertinent system entities usually suggests they no longer fall under the umbrella of a single organisation. Eventually, there is the notion of the heterogeneity of both the hardware and software components, additionally expanding into and reshaping the services provided on top of them, which together with the enablers mentioned previously appear to transpose today's networked computing systems much more into a melting pot comprising a broad variety of concepts and approaches, thereby more and more profoundly calling for the incorporation of self-sustainable operation in order to facilitate the instantiation of the ultimate concept of autonomic networking (Wódczak, 2014).

All in all, recalling the biological origins of autonomics along with its business-motivated orientation yet technologically varying enablers, and taking into account the convergence-driven and hardware-based similarities between the computing and networking aspects, not to even mention the prevailing role of software in the sense of being responsible for overseeing its underlying hardware and especially for the orchestration of its own routines, a variety of not always fully justified understandings of autonomics have been established. In fact, the author has determined that, in practice, whenever a comprehensive definition of this term is attempted, sooner or later a mixture of connotations is brought up which only makes it even more obfuscated. Before this issue is to be scrutinised in detail in the section to follow, one should note that, in principle, not only does the idea of autonomics assume a virtually entire exclusion of any human-related involvement, even though it may still refer to the role of an administrator for the task of distributed computing system operation and maintenance, but it also requires that such a system not be perceived as cognitive in the sense that it cannot reason by itself. Following Kephart and Chess (2003), such a unique combination of functionalities pretends to be achievable exactly through an inherent ability of this kind of a system to self-manage with a special emphasis on continuous monitoring of internal and external conditions, as well as applying relevantly imposed policies and taking pertinent actions.

2.2.2 Nomenclatural Perspectives

In the light of the above context, as the extent of convergence between the worlds of computing and networking appears to have gone well beyond any conceivable boundaries, by no means could the nomenclatural perspectives on autonomics remain tightly restricted or focused, especially since it has started to become more difficult to tell the related core technologies clearly apart, not to mention the influence of the already introduced biological connections. In fact, the boundaries between computer systems and their related interconnecting telecommunications networks seem to have gradually disappeared, and hybrid solutions started to materialise, as indicated by Phan (2009), making attempts to draw a distinction between the two realms somewhat artificial, if adequate at all. Irrespective of the fact that computers and networks have come to be perceived as a unified entity, the notion of autonomics has started becoming more and more vague, especially due to the seemingly perpetual confusion over what should be meant by autonomy and automation (Wódczak, 2014). In order to shed more light on this aspect, as well as to account for the proper meaning of and differences between the related semantic fields, an attempt is made below to introduce autonomics through an explanation of the role of awareness. Then, a wider context of multi-agent systems (MASs) and decision-making elements (DMEs)⁴ is highlighted, just to conclude with what should be really meant by the notions of being autonomic, autonomous, or cognitive.

Looking at the technological progress, one can discern not a steady but an exponential increase in the adoption of the more and more ubiquitous software-based components and entities into the world of networking. To emphasise the significance of this phenomenon, following Mainsah (2002), one could suggest that, should the aircraft industry experience growth of the same order, ‘transatlantic flights would take no more than a few minutes and cost no more than a few dollars’. Attempting to pinpoint exactly what the main incentive for such development could be, it transpires that one of the key drivers for the related convergent advancement results directly from the need of an autonomic networked design to be self-contained in the sense of being capable of behaving in a self-aware manner. In an abstract sense one may claim that, as such, self-awareness⁵ could go hand-in-hand with autonomics, because of the assumption that the system should exploit all the acquired knowledge to ‘understand’ its own status change and the implications. However, following the classification outlined by Vassev and Hinchey (2010), as illustrated in Figure 2.2, one may clearly notice that self-awareness is not a standalone feature, but is complemented by the concept of context-awareness, emphasising rather the external aspects (Chiti et al., 2016). From such a perspective, context-awareness may be understood more as the ability of a system to interact with its environment through communication and negotiation for the purposes of being able to predict any forthcoming situational changes in advance.

Most importantly, however, not only do both the notions of self-awareness and context-awareness revolve around the aforementioned focal component of autonomics in the form of knowledge, but each of them is, respectively, further composed of two functional entities referred to as recognition and monitoring, as well as learning and assessment (Figure 2.2). According to Vassev and Hinchey (2010), the task of recognition must be defined to correspond to the exploitation of knowledge for the purposes of tracking changes, while the function of monitoring provides all the data necessary for building such knowledge by means of collecting, aggregating, and processing the acquired information. The complementary role of assessment, then, relates to testing hypotheses and identifying situational schemata, while at the same time being responsible for triggering the process of learning, consisting in the formulation of similar new schemas and keeping track of the system evolution history (Vassev and Hinchey, 2010). Given such a context, and the supporting literature, one may conclude that there seems to be much more to self-awareness than the initially assumed direct correspondence with autonomics. What is more, the meaning of autonomics should not be confused with cognition and reasoning, because as long as self-awareness clearly involves the processes of learning, it may also imply a bit more than simple monitoring for purely mechanical context recognition. All this adds substantially to the emergence of the previously mentioned spectrum of different perceptions of autonomics, resulting in the lack of a commonly understood and agreed definition.

In essence, regardless of the increasing number of scientific and industrial works on autonomics, ranging from more conceptual ones to their purely standardisation-orientated counterparts, it continually appears that the positioning and nomenclature of this concept are still evolving, while carrying a certain element of vagueness. In particular, as argued by Kephart and Chess (2003), the very concept of autonomic computing is claimed to be deeply rooted in the theory of agent systems (ATSs), since autonomy, proactivity, and goal-directed interactivity are the major distinguishing characteristics of software agents (SAs). What is more, not only does autonomic computing span single-agent systems (SASs) and multi-agent systems (MASs), but it also encompasses the rationale behind the aforementioned service-oriented architecture. Such a conclusion results directly from a comparison of the following definitions of autonomic computing and software agents, as observed and cited by Brazier et al. (2009), which contrast ‘computing systems that can manage themselves given high-level objectives from administrators’ with ‘an encapsulated computer system, situated in some environment and capable of flexible, autonomous action in that environment in order to meet its design objectives’. As much as they come from different sources of Kephart and Chess (2003) and Jennings et al. (1998), respectively, despite some contrast, these definitions clearly appear to go hand in hand. Reading into the details one may notice, however, that even though the definition of a software agent refers to the notion of being autonomous, there is no hint of autonomics.

Going further, while these definitions clearly revolve around the semantic field originally attributable to automation, the expression of autonomy⁶ appears to induce more the lack of human control, while that of autonomics clearly draws from the employment of the principles behind the functioning of the human autonomic nervous system. This immediately implies that, even though there might exist a similar temptation to put both the notions of being autonomic and agent-driven under the same umbrella, a certain dose of prudence is necessary to avoid any unintended introduction of an accidental bias related to the proper understanding of the term of autonomics. What is more, seeking direct correspondence between the two concepts, one could rely on the existence of individual self-managing decision-making elements, making it possible to perceive the autonomic computing system in question from the perspective of a multi-agent system, as such a system would be composed of multiple subsystems or services, while an agent system would comprise multiple agents (Brazier et al., 2009). This is, in fact, where the related service-oriented architecture context appears on the horizon and enters the global picture of the sought-after synergy between autonomic computing and multi-agent systems. This way, decision-making elements could be claimed to fairly well resemble software agents in the sense that, normally, the latter would similarly act on the basis of both monitoring the data from sensors and applying the imposed policies (Brazier et al., 2009). Still, despite all the tight links between these approaches, one needs to be careful to avoid any warping of the sense of autonomics by attributing to it what should not really belong there (Wódczak, 2014).

In fact, even though the role of semantic fields could be regarded as an ignorable detail in this respect, a more thorough analysis unfortunately makes this no longer appear to be so (Wódczak, 2014). In particular, even from a purely linguistic perspective, the word ‘autonomous’ seems to bring two major connotations of relevance to the argument. As such, the pertinent definitions derived from the market-leading dictionaries tend to classify the notion of being autonomous as ‘having the ability to work and make decisions by’ oneself and ‘without any help from anyone else’, in other words independently, according to Gadsby (2003), or making one's decisions on one's own ‘rather than being influenced by somebody else’, to follow Sinclair (1997).⁷ Following the above course of thinking, the quality of being autonomous may apparently be attributed to a system of a standalone type in the sense that it is self-sufficient and, thus, may operate on its own, without any need for external intervention or orchestration, i.e. as a fully separate entity. Most obviously, this perception does not necessarily need to imply a full semantic overlap with autonomics, as depicted in Figure 2.3. Quite the contrary: one may also consider a more cognitive flavour, where the system is autonomous in the sense that it exposes an advanced capability for reasoning. Such a quality, in turn, could manifest itself through the ability to make decisions driven by some hidden logic, just as if the system were steered by a brain-like device. Not surprisingly, this connotation is also not particularly useful, as autonomics detaches the features of the human autonomic nervous system from any learned decisions the brain could be responsible for (Wódczak, 2014).⁸

Given the above context, and progressing with the argument, the notion of being autonomic seems somewhat intangible in the sense that it may be understood in a number of sometimes clearly disjoint ways, thereby making the overall process of establishing a widely acceptable definition even more difficult, if possible at all. In fact, one may account for such a situation by analysing the potential reasons leading to the related terminological confusion, chiefly resulting from unjustified attempts at perceiving some other flavours of orchestration as if they were supposed to incarnate the autonomic one, while not really qualifying to be considered so. Thus, one may immediately stumble across misunderstandings related to being autonomous that may be classified as belonging to a disjoint semantic field, and consequently understood in a different way, having little or nothing to do with autonomics. This is because the perception of ‘being autonomous’ most obviously leans towards semantically overlapping with, or being partially equivalent to, being independent in the sense of functioning in a standalone or detached manner. Yet, while such a characteristic feature could be justified as an enabler of autonomics, it does not necessarily need to be so. What is more, the very fact of being autonomous could go beyond the notion of awareness, more or less directly translating itself into the capability of acting in a cognitive manner in the sense that a system possessing such an ability would be entitled to reason in a human-like manner, solely relying on brain-resembling logic to take decisions.

2.2.3 Towards Self-Management

This variety of impressions of being autonomous does not even come close to the proper perception of autonomics, even though cognition could well work together with autonomics, so long as a clear distinction is made between the two. And yet, expanding the scope of analysis, one may inevitably come across the notion of an automated system where the difference from autonomics appears to be even more conspicuous, as what should be normally understood in this respect clearly boils down to the more and more passé approach of script-language-based programming. In other words, the confusion in this respect may apparently arise from the fact that the grammatical form of being automated may be understood either as if it were reflexive, where some internal drive could be expected to exist, or as if it were triggered externally, where the overall operation would be prescribed well in advance. It so happens that, while the former appears to be a reasonable justification for making the semantic field of the word ‘automated’ even closer to that of‘ autonomic’, yet still not overlapping, the latter explanation is, in fact, what the experts in the field of network management would actually mean when using it. For the sake of shedding more light in this respect, this section opens with a wider context, going beyond what one could name as the domain of networking or computing. Next, given the observation made by Kephart and Chess (2003) that the ‘essence of autonomic computing systems is self-management’, the major pillars of self-configuration, self-optimisation, self-healing, and self-protection are scrutinised. Finally, the placement of autonomic features on proper levels of assignment is discussed for organisational purposes.

In essence, looking from a wider perspective, maybe even a bit unexpectedly at first sight, yet most naturally in general, similar notions of a relevant form and type appear to have been deployed similarly way beyond networking, for example in the remote exploration of outer space, where one may come across a definite distinction between the notion of autonomics and autonomy, perfectly addressing the purpose of this explanation.⁹ In fact, as claimed by Truszkowski et al. (2006), ‘while autonomy supports cost-effective accomplishment of mission goals, autonomicity supports survivability of remote mission assets, especially when tending by humans is not feasible’. One should note, however, that as much as it is useful to account for the notion of self-management, the above citation, somewhat unintentionally, brings up yet another issue, thoroughly discussed in standardisation and pertaining to the word ‘autonomicity’, which does not appear to exist in the major dictionaries of the English language. This term was similarly coined within the specifications released by the aforementioned ISG AFI under the auspices of ETSI. Unfortunately, as observed by the author, even though the notion of ‘autonomicity’ is gaining more and more recognition among the experts, who are continually trying to find the most accurate expression to reflect the hardly tangible meaning, this word appears to be not very well received by native speakers of the English language and should be used rather carefully, with a proper commentary fully justifying the act of doing so, as indicated by Wódczak (2014).

Since self-management turns out to follow the pattern of a circular process, as outlined in Figure 2.4, it appears fairly obvious to commence the analysis of its constituents with the component of self-configuration related to the initial orchestration of an entire selection of software and hardware entities, potentially devised and provided by various vendors, with the inclusion of, yet not implying any limitation to, elements such as databases, routers, or servers (Kephart and Chess, 2003). Bearing in mind the aforementioned complexity of currently deployed networked computing systems, the most appropriate configuration of such entities may become critical from the time consumption perspective, especially in the light of any initially unforeseeable, and not immediately solvable, interoperability issues (Wódczak, 2014). This aspect becomes substantial for distributed configurations, where an overwhelmingly high number of network nodes makes any manual effort towards their holistic orchestration highly impractical, particularly cost-wise. Consequently, it becomes of prime importance for an autonomic computing system to identify its own capabilities in order to apply a selection of relevant predefined high-level policies to perform proper self-configuration. Once the above task has been accomplished, it might be necessary to either further align the existing setup or react to any fluctuations in software or hardware configuration dynamically with the aid of the next component – self-optimisation – generally perceived more as being responsible for tuning specific parameters through the adjustment of software and hardware settings.

In fact, when the case of self-optimisation is concerned, the parameters inherent in software should not be mistakenly confused with those residing in hardware, as the process of tuning either might be perceived as being entirely rooted in software (Wódczak, 2014). As indicated by Kephart and Chess (2003), since it is not uncommon knowledge that every single system release drastically increases the number of such parameters, it transpires that, as for self-configuration, the task of manual optimisation becomes virtually impossible to be accomplished without the incorporation of some relevantly designed Autonomic Routines. This is where self-optimisation comes into the overall picture of self-management, as it is not only expected to be triggered when a new software or hardware component has been installed, but as a reoccurring operation evoked in a manner resembling the functioning of the human autonomic nervous system in order to allow modifications to be performed on the fly according to additional guidelines stemming from the overlay formed by a specifically designed management plane (MNP) (Wódczak, 2014). Once an autonomic computing system has executed and successfully accomplished both the tasks of self-configuration and self-optimisation, it might require further monitoring to accommodate another key feature of self-management, known as self-healing, an even more dynamic process of analysing the current system status in relation to previously acquired data, so that it is possible to react to issues in virtually no time and guarantee uninterrupted operation.¹⁰

The reason for such continuous monitoring is related to the fact that the higher the complexity of deployed networked computing systems becomes, the more difficult it appears to identify, trace, and determine the root causes and symptoms of a given incident or a group thereof, especially when additional and unexpected mutual interrelations arise, to follow Wódczak (2014). In fact, as indicated by Kephart and Chess (2003), any nonautonomic approaches attempting an exhaustive analysis of the said root causes may consume several weeks of demanding effort and still result in a rather vague or intangible diagnosis, not to mention the case when the root cause may have suddenly ceased to exist. As such, the described approach to self-healing belongs to the class of predominantly resilience-related solutions, where the system itself is capable of observing any relevant incidents well in advance, which means way before they have caused or contributed to any issue, so that it is possible to react properly beforehand to potentially avoid any otherwise imminent implications, as advocated by Wódczak (2011b). Thus, the requirement of self-healing may become perceived as substantially correlated with self-protection, at the same time exposing certain similarities with the management of system faults. In fact, due to the mutual relations between resilience and fault management, the approach based on inference from symptoms may undoubtedly be even more related to the ultimate component of self-protection.

Given the above context, and keeping in mind the circular nature of the process of self-management, it is possible to shift the point of view a little to look at Figure 2.4 not from the above, but from the side. Then, all the four constituents of self-management could be imagined to reside on the same level and, once separated more significantly, they would naturally form a much more linear configuration, as depicted in Figure 2.5. Such a conceptually transposed representation, where the viewpoint is clearly located somewhere between self-configuration and self-protection, so exactly at the point where the process of self-management reiterates, taking the form of a presumably horizontal arrangement, makes it possible to further subdivide each of the components of self-configuration, self-optimisation, self-healing, and self-protection into two sublevels. In fact, as classified by Brazier et al. (2009), autonomic functions (AUFs) naturally need to be performed at both the application and infrastructure levels, thereby creating a logical separation within the previously described tight, or even overlapping, relation between the realms of computing and networking, where certain aspects advocating for the deployment of automation encompass the baseline concepts behind autonomic system design as a whole. The main driver for such a separation is to maintain sufficient distinction between software and hardware, which, clearly, may pose certain additional challenges, as, especially nowadays, more and more hardware devices appear to carry the ‘software-defined’ label (Wódczak, 2014).

All in all, the system would need to autonomically detect and resolve any unexpected malicious behaviour or cascading failures (Kephart and Chess, 2003), so that the data collected during the monitoring phase could be properly filtered in order to extract any potential root causes and, thus, reason about as yet unknown, but sufficiently probable, potential issues. In fact, while self-protection should provide the measures necessary for failure avoidance, consisting chiefly in problem mitigation, self-healing appears to be more of a remedial nature (Wódczak, 2011b). This would mean, in turn, that both mechanisms should interact and base their functioning on the aforementioned tasks of self-configuration and self-optimisation. Obviously, such functionality may only be attained gradually, and it is assumed that initially all of the components would need to be considered and deployed separately. However, with the passage of time, as self-configuration, self-optimisation, self-healing, and self-protection become more and more welded together, this process could require the evolution of the self-management component in a more generic way, i.e. as a consistent concept (Kephart and Chess, 2003). Thus, autonomics would first solely provide help in collecting all the data an administrator could use to support the decision-making process. Then, the role of autonomic control processes would be expected to be elevated to the level of suggesting certain actions to the human, and finally such processes would function in an entirely standalone and detached fashion, basing their intelligent decisions on the actions of the other lower-level control routines (Kephart and Chess, 2003).

2.3.1 Generic Autonomic Network Architecture

In the light of the inclination towards the ultimate convergence¹¹ of autonomic computing and autonomic networking, a relevant concept in the form of the Generic Autonomic Network Architecture (GANA)¹² was originally proposed by Chaparadza (2008), at that stage still not encompassing any comprehensive cooperative design, and then further advanced through standardisation, as described by Wódczak et al. (2011).¹³ Even though the initial objective of the Generic Autonomic Network Architecture originally revolved around autonomics while remaining distinct from the notion of being autonomous, not to mention the aspect of cognition, its actual instantiation should be never perceived as entirely exclusive of the possibility of exercising any cognitive or autonomous operation. Quite the contrary: what has materialised as a result of a predominantly evolutionary approach could be referred to as a structured categorisation of all the pertinent and related notions for achieving a multifaceted system design. In order to prepare the ground for the Autonomic Cooperative Networking Architectural Model (ACNAM), it is necessary to introduce the baseline design principles adopted by the underlying concept of the Generic Autonomic Network Architecture. To this end, first of all, a more generic perspective of a planar approach to architectural building blocks will be introduced, to be followed by a still high-level blueprint, concluding with the rationale behind the intrinsic signalling tools and methods, before more advanced topics may follow.

At this stage of the analysis, the perspective of autonomics may seem to already have shifted towards autonomic networking, especially since the Generic Autonomic Network Architecture builds upon the 4D Architecture, introduced by Greenberg et al. (2005), where the following four major planar components are distinguished: the decision plane (DCP), the dissemination plane (DMP), the discovery plane (DSP), and the data plane (DTP).¹⁴ As such, the Generic Autonomic Network Architecture fully adopts the above-mentioned planes, and also retains their respective naming structure, which further highlights its evolutionary flavour, as outlined in the ETSI-GS-AFI-002 (2013) Group Specification (GS). Moreover, there is also the knowledge plane (KNP), which is maybe not openly enumerated in the ETSI-GS-AFI-002 (2013) GS, but is inherent in its major drawings, chiefly in adding the said flavour of cognition¹⁵ as defined by Clark et al. (2007). Given such a context, and looking in particular at the DTP, one may notice that its major responsibility is to make all the decisions related to the orchestration of the so-called autonomic nodes (ANOs), including the aspects of ‘reachability, load balancing, access control, security, and interface configuration’; this is so because nowadays the DCP has replaced the already legacy management plane by operating in ‘real time’ and assuming a ‘network-wide’ perspective (ETSI-GS-AFI-002, 2013). In fact, such a view will be directly and fully attributable not only to the yet to be introduced notion of the levels of abstraction and their pertinent hierarchical autonomic control loops, but also the remaining three planes.¹⁶

Similarly, the dissemination plane encompasses additional protocols and mechanisms, as prescribed in the ETSI-GS-AFI-002 (2013) GS, to ensure sufficiently reliable communication capabilities, allowing for control information such as monitoring data to be safely and efficiently conveyed to the hierarchical autonomic control loops, so that well-informed decisions can be taken by the decision-making elements residing within the DCP. Equally important, yet differently positioned, is the DSP, which makes similar use of specific protocols and mechanisms to identify the physical and logical constituents of a given network or service. This feature is especially valuable when the question of capability discovery is taken into account, as despite the fact that network devices may use self-advertisement to disseminate their characteristics, there might still exist a need for mechanisms capable of collecting such data and exploiting the acquired information for the sake of autonomic networked system orchestration. Last, but not least, comes the DTP, which involves protocols and mechanisms intended to enhance the traditional network layer (NET) protocols such as the iconic Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), using the control and orchestration provided by the DCP (ETSI-GS-AFI-002, 2013). In fact, all the discussed entities are immersed in the Generic Autonomic Network Architecture along with their related decision-making elements¹⁷ and hierarchical autonomic control loops.

Moving forward, as described in the ETSI-GS-AFI-002 (2013) GS, one of the key aspects of the Generic Autonomic Network Architecture is related to the existence of the inherent functional blocks (FBs) and their respective reference points (RFPs), not only for the sake of internal orchestration, but particularly to enable open interaction with architectures defined by other standards development organisations (SDOs), such as the 3rd Generation Partnership Project (3GPP), for example, where the highly pertinent concept of self-organising networks (SONs) is being advanced (Meriem et al., 2016). Given the nature of the Generic Autonomic Network Architecture, as depicted in Figure 2.6, a staged roll-out of its major constituents was prescribed to be orchestrated in a top-down manner, originating from the KNP where network level (NTL) decision elements (DEs) would normally reside, down to the network elements (NEs), where all the remaining node level (NDL), function level (FNL), and protocol level (PTL) decision elements would be located.¹⁸ Not only does such a composition facilitate the overall instantiation process, but it also allows for proper coordination of autonomic functions (AUFs) for the sake of stability and scalability provisioning, which requires that the hierarchical autonomic control loops be designed to guarantee non-coupling and non-conflicting behaviour, as outlined in the ETSI-GS-AFI-002 (2013) GS. Still, given the fact that the hierarchical autonomic control loops may condition any interaction between such autonomic functions, it is necessary to note the role of the relations between or among DEs, which extends to involving their respective managed elements, too.

In fact, the DEs, as further detailed in the section to follow, play an instrumental role in the instantiation of the related autonomic behaviour (AB), since they attempt to identify and determine a state of equilibrium, while being continually triggered by various signals calling for interaction, in the form of either commands from upper-level DEs or events from managed elements, as well as policies or data monitoring¹⁹ (ETSI-GS-AFI-002, 2013). Consequently, in certain circumstances, the freedom of a DE to make a decision on the basis of information it already possesses may equally well be limited by certain directions issued by some other entity. These signals are conveyed in the form of so-called characteristic information (CI) over specifically defined reference points, as show in Figure 2.7. This is where the KNP comes into the picture, as defined by Clark et al. (2007); it interweaves with the network level and adds an element of cognition, required especially when complex decisions need to be taken, to make it feasible for the networked system to perform tasks of a global scope, imposed, for instance, with the highest priority by an administrator or operator.²⁰ In parallel, certain local arrangements, such as the yet to be defined Autonomic Cooperative Behaviour (ACB), could be carried out seamlessly and without interruption, clearly as long as any of the policies in force are not being violated. As will be discussed, whether to exercise Autonomic Cooperative Behaviour at the node level or network level, or maybe assuming a broader scale, might depend on multiple characteristics and specific conditions (Wódczak, 2014).

Analysing the above-mentioned components, one could conclude that a working definition of autonomic networking could be approximated as an ability to align the ongoing operation of a networked system with the requirements arising not only from the collected monitoring data, but also from any externally or internally imposed policies, where all of those factors would be presumably changing over time in a continuous manner and at a varying pace (Wódczak, 2014). What is more, such processes should be expected to be observable at each level of abstraction, and only such an assumption would possibly lead to the ultimate impression that what distinct autonomic nodes of the baseline²¹ Generic Autonomic Network Architecture would express, in that sense, could be most naturally categorised as autonomic behaviour. As such, the notion of autonomic behaviour is tightly bound with the concept of an autonomic node which, being a core part of the Generic Autonomic Network Architecture, appears to be somewhat self-contained or even, theoretically, detachable, since the network level, where, in specific cases, the relevant global decisions may need to be taken, might function or exist only conceptually, as it is formed by purposely elevated network nodes, otherwise belonging to the node level (Wódczak, 2014). In fact, following the ETSI-GS-AFI-002 (2013) GS, autonomic behaviour is defined to be composed of sub-behaviours or subactions originating from DEs with the intention of achieving a prescribed objective, triggered either externally or internally, or possibly instantiated spontaneously.

2.3.2 Decision-Making Entities

As the conceptual background outlined so far is advanced even further, the transition from the original concept of autonomic computing to its current incarnation in the form of autonomic networking may start to become more conspicuous, mostly due to the accompanying translation of all the relevant nomenclatural and structural patterns. In fact, the initial concept of autonomic computing assumes that a system expressing such a capability should comprise numerous so-called autonomic elements (AEs) as the most comprehensive, yet not entirely atomic, constituents. As such, those AEs are expected not only to contain resources and deliver services, but also be able to manage their own behaviour and act pursuant to certain policies, imposed either internally, i.e. by other AEs, or externally, i.e. by a human operator. Thus, assuming continuous interaction, an autonomic system should be able, as indicated by Kephart and Chess (2003), to attain the level of ‘social intelligence’ inherent in a living ant colony.²² Such a capability could not impose any particular notion of being cognitive, because even when imitated, the colony would never act as a single organism, but rather assume the form of a collection of components notifying one another and acting according to directions or rules.²³ In order to account for the instantiation of the pertinent architecture, first of all, the notion of legacy autonomic elements is presented in the light of the more up-to-date concept of DEs.²⁴ Based on this, the paradigm of an autonomic node is to be introduced as a high-level container thereof, maintaining a more virtual nature, in order to pave the way for the architectural considerations to be outlined later in the book.

In fact, the underlying question of the complexity of an autonomic system may become one of its inherently most critical characteristics in terms of guaranteeing properly accurate maintenance as understood through the aforementioned notion of self-management. Since such complexity might call for special operational tools, it was proposed that it should be tackled with and orchestrated by the application of the mathematical device of utility functions (UFs), as implied by Kephart and Das (2007), primarily devised to serve as a means of facilitating the task of preference specification, while spanning widely over the complementary domains of economic sciences (ESs) and artificial intelligence (AI). Clearly, the said utility functions allow for the specification of a multitude of parameters, based on which fully scrutinised actions could be taken by relevant DEs, as the original ‘rational decisions’ of ‘automated agents’ would be referred to in this context (Kephart and Das, 2007). Going further, as explained by Vassev and Hinchey (2010), a learned decision-making process certainly requires the acquisition and analysis of all information of relevance for the sake of knowledge collection and extraction. Similarly, the said parameters are claimed to directly translate into resource-level indicators or, even more straightforwardly, into the related metrics based on quality of service (QoS), intended not only to facilitate the formulation of the optimisation function but, most of all, identification of ways of addressing and solving the complexity issues, as outlined by Kephart and Das (2007). This calls immediately for a more detailed explanation of the workings of architectural designs based on autonomic computing.

Interesting though it may seem, and quite contrary to the follow-up developments, vastly capitalising on the core concept of autonomic computing, this legacy approach itself was proposed under the assumption that the distributed decision-making logic would be encapsulated within the aforementioned autonomic elements. Yet, as might have already become clear, the most recent designs, and the Generic Autonomic Network Architecture in particular, appear to rather expose the internals, thereby modifying the notion of an autonomic element, especially when perceived from the global perspective. In fact, as depicted in Figure 2.8, an autonomic element is normally composed of an autonomic manager (AM) and a managed element (ME), working in very close relation thanks to the existence of an autonomic control loop (ACL), which may work at a varying pace, as indicated by Yixin et al. (2005).²⁵ As the idea of autonomic managers has nowadays transitioned into the concept of decision elements, the functionality equivalent to a managed element is usually referred to as a managed entity (MEN), being orchestrated with the aid of a ‘reformulated’ hierarchical autonomic control loop.²⁶ Yet, it is crucial to note that the inherent feature of each autonomic manager, at the same time serving as its central and focal point, is the notion of knowledge, surrounded by the components of monitoring, analysis, planning, and execution.²⁷ This is, in fact, where the major difference between autonomic managers and decision elements becomes conspicuous, mostly due to the prevailing assumption that the encapsulation-like approach to distributed decision-making logic be evolved respectively.

Given such a context, moving, bottom-up, towards more abstract developments, a high-level depiction of the so-called autonomic node²⁸ is introduced, as shown in Figure 2.9, where the approach to the distributed decision-making process advocated by the Generic Autonomic Network Architecture is visible. In essence, such an autonomic node²⁹ is envisaged as composed of those three out of the aforementioned four levels of abstraction which may be characterised as exclusively internal when contrasted with the network level. The different nature of the latter results from the fact that, in a sense, it should rather be perceived as if it were an abstraction of an abstraction, especially since it is not physically attributable to any realistically quantifiable entity. Looking more into such ‘internal’ levels of abstraction, one may discern immediately that decision elements should not be perceived as being atomic, since they might be further subdivided into sub-decision elements (SDEs). In general, however, since this type of subdivision is expected to be present at the node level, the question arises whether the node main decision element might be perceived as an aggregation of fully-fledged decision elements, with additional prefixing employed for linguistically justified nomenclatural consistency. One way or another, preceding a more detailed analysis of both the levels of abstraction and hierarchical autonomic control loops, as much as there are obvious differences between the conceptual construction of autonomic elements and decision elements, there are also sufficient similarities to make the ideological inheritance clearly conspicuous.

Keeping in mind the high-level structural depiction of an autonomic node, as well as the mutual interrelationship between decision elements, especially when perceived from the viewpoint implied by the framework of the levels of abstraction, it becomes most natural to generalise the information exchange between such decision elements, as advocated by the Generic Autonomic Network Architecture, where the already described characteristic information is conveyed over the said reference points.³⁰ In particular, on the one hand, it is clear that the related interfacing process is orchestrated by the hierarchical autonomic control loops, where the policies of relevance are injected, either internally or externally, on the basis of inferences drawn from monitoring data. On the other hand, though, drawing a comparison between the legacy approach as envisaged by Kephart and Chess (2003) and the currently evolving designs, such as the Generic Autonomic Network Architecture itself, it transpires that the general distinction that apparently still exists between the role of an autonomic manager and a managed element could be further relaxed to become predominantly conceptual, when mapped onto the corresponding tandem formed by a decision element and a managed entity. In other words, especially when higher levels of abstraction are concerned, due to their mostly abstract nature, the managed entity may resemble the functionality and take the form of a decision element. Obviously, such a pattern may not fully hold at the lowest of the levels of abstraction, since the external protocols under control normally do not embody any intrinsic replica of the above-mentioned concepts.³¹

In this respect, before any specific data in the form of the above-mentioned characteristic information, encapsulated into proper messages, could be exchanged in a standardised manner over the said reference points, some internal preprocessing may need to be performed by the logic embedded in the corresponding decision elements. As such, the decision elements are supposed to undertake actions in accordance with the objectives imposed upon them, at the same time satisfying the assumption that the overall design remain within the flexibility frames of the Generic Autonomic Network Architecture. What is more, given the assumption of the existence of not only horizontal, i.e. peering or sibling, but also vertical, i.e. parental, relations, one may imagine a three-dimensional grid of decision elements attempting to fulfil the nontrivial task of maintaining the overall state of equilibrium of the autonomic system, while concurrently making the utmost effort to meet the aforementioned objectives. This may, once again, recall the biological analogy of the ant colony, thereby highlighting the ever returning question of the hardly tangible difference between the notion of being autonomic and the notion of being able to reason, just as if there had been any process of thinking in place. As already described, being separate organisms, ants would be said to move around together as a symbiotic group at most, this way conceptually becoming fairly alike to the similar interaction among human body organs, where the living processes could not be explicitly orchestrated with the aid of thinking, but instead result from the autonomic behaviour of such organs also forming a somewhat symbiotic arrangement.

Thus, the decision elements could be perceived more as configurable entities facilitating an object-orientated system design from the architectural perspective, while allowing for their functionality to be further split, shifted, or translated, which appears to remain fairly in line with the rationale behind autonomic system design on the one hand, yet certainly brings in the risk, or maybe rather the opportunity, of expanding the said functionality of being able to reason, so that AI-related approaches could be exercised equally well, on the other hand. Looking particularly from the perspective of the lowest-level decision elements it becomes obvious that they need to communicate with their respective managed entities over well-defined and preferably standardised interfaces which may create a much more rigid, limited, and ‘hard-coded’ environment, following the nomenclature of Kephart and Chess (2003). However, should a slightly broader view be assumed, it could naturally transpire that, regardless of the evolution stage of a particular instantiation of the concept of autonomic computing, both the original design and the most recent developments thereof, such as the Generic Autonomic Network Architecture, tend to be rather strongly based on the assumption that the decision elements need to manage not only their internal behaviour, but also external interactions (Wódczak, 2014). Such interactions mostly translate into the exchange of well-defined and well-structured signals or messages with other decision elements, once again putting a special emphasis on the inclusion of the external world, both in the microscopic and macroscopic context, as originally advocated by Kephart and Chess (2003).

2.3.3 Abstraction Levels and Control Loops

The levels of abstraction originating from the Generic Autonomic Network Architecture could not be reflected upon exhaustively should they not be put against their corresponding hierarchical autonomic control loops. In general, following what has already been signalled, one may distinguish between four disjoint levels of abstraction from the top network level, through the node level and the function level, down to the protocol level. Apart from their respective hierarchical autonomic control loops, each level is characterised by its inherent decision elements, thanks to which the process of interaction between them takes place in both a top-down and bottom-up manner. In particular, such interaction is performed with the aid of vertical reference points (VRPs), i.e. over hierarchical autonomic control loops between hierarchically-orientated decision elements in the vertical dimension, as well as through horizontal reference points (HRPs), directly between their peer or sibling counterparts in the horizontal dimension. Thus, each decision element may retain its exclusive responsibilities without becoming subject to any restrictions where the allowed interaction among all of them or their respective subsets is concerned (Wódczak, 2014). However, such a design might turn out to become highly complex and, therefore, have substantial implications on the overall stability and scalability of the autonomic system in question. The above issue may be addressed through the adoption of a specific approach to the definition of the role and scope of the hierarchical autonomic control loops, as outlined in the ETSI-GS-AFI-002 (2013) GS.

In fact, analysed either in the top-down or bottom-up direction, the multi-tier arrangement of the internals of the Generic Autonomic Network Architecture appears to create an otherwise highly evocative impression that the entire setup would be managed in a substantially hierarchical manner. Unsurprisingly, the higher the level of abstraction, the broader the scope of certain decision elements and their respective hierarchical autonomic control loops becomes; in particular, the scope of control of any of such decision element spans recursively over the numerous lower-level decision elements to be overseen, as well as over the respective hierarchical autonomic control loops to be orchestrated. What is more, it is necessary to highlight that, generally, the higher the level of abstraction, the lower the pace at which a given hierarchical autonomic control loop should be running (Wódczak et al., 2011). Thus, the autonomic system may be expected to demonstrate scalability, as it should always allow for the incorporation of ‘parent’ decision elements at a specific level of abstraction in order to orchestrate the behaviour of their ‘child’ decision elements. One should also note, however, that in the case of a decision element at the protocol level, there would be no level of abstraction below, so that such a decision element would normally orchestrate the external resource of a managed entity, usually with a relevant protocol.³² Complementary to scalability would remain the said pace a given hierarchical autonomic control loop be running at which shouldchange with the level of abstraction to guarantee a sufficient degree of stability.

In the following, all the levels of abstraction are to be characterised in reverse order on the basis of their respective hierarchical autonomic control loops and in accordance with the ETSI-GS-AFI-002 (2013) GS. Commencing from the bottom protocol level, as depicted in Figure 2.10, the relevant hierarchical autonomic control loop is orchestrated by the protocol level decision element which interfaces with a managed entity in the form of a software driver supervising a specific protocol, most likely belonging to the Open Systems Interconnection (OSI) or Transmission Control Protocol/Internet Protocol (TCP/IP) stack, as outlined by Wódczak et al. (2011). The particular protocol might take either a modular or monolithic shape and, potentially, even be equipped with its own intrinsic autonomic control loops (ACLs)³³ not originating from the Generic Autonomic Network Architecture design, particularly since, according to previous note, the deployment of hierarchical autonomic control loops within protocols may not be recommended to keep them simple and driven directly by the Generic Autonomic Network Architecture.³⁴ Moving upwards, immediately above the protocol level resides the function level, as outlined in Figure 2.11, mostly encompassing the so-called ‘abstract network layer functions’, and not really the protocols themselves (ETSI-GS-AFI-002, 2013). Such a function may incorporate, for instance, the general functionality of routing or mobility management. Thus, the role of the function level consists in the proper configuration of specific protocols with the aid of hierarchical autonomic control loops intended to facilitate the process of event monitoring and tracking.

One next comes across the node level, being the highest physical entity of this sort, as the network level to follow is more of a conceptual, though still practical, nature. As such, being located right above the function level, the node level contains the logic responsible for the autonomic node as a whole. Thus, as outlined in Figure 2.12, not only is the node level decision element granted direct access to the requirements exposed by the function level decision elements, but it may access all the information pertaining to the internal priorities of the node level itself, as advocated by the ETSI-GS-AFI-002 (2013) GS. What is more, because it takes its directions immediately from the network level decision element, it may be perceived as a kind of a hub responsible for the entire autonomic node. However, since a corresponding physical network device cannot be claimed to exist, at least not in the form of a single piece of hardware, the network level should be perceived as being formed by some purposely elevated autonomic nodes, characterised by extended capabilities.³⁵ Since only a single network level decision element should exist, as presented in Figure 2.13, it could become rather complicated because of its elevated nature. For this reason, it would be recommended that the core functionality of this decision element should follow a modular pattern, so that a conceptually centralised design could capitalise on being physically detachable. Consequently, a fully distributed solution could be implemented, where there would be multiple network level decision elements to make decisions of a global scope in a cooperative manner (Wódczak, 2014).

2.4.1 Vertical Technological Pillars

Given the background of the introduction of the workings of autonomic computing per se, as well as with the complementary discussion of the rationale behind its evolved incarnation in the form of the Generic Autonomic Network Architecture, the time has come to provide a comprehensively detailed, yet still correspondingly high-level, outline of the synergetic approach to autonomically driven cooperative networked system design to be advocated in this book. In this respect, first of all, the major technological pillars,³⁶ conceptually assumed to follow a vertically orientated pattern, will be introduced in this subsection, to be later complemented with newly proposed horizontally orientated architectural extensions, so that it is possible to present a fully-fledged and incrementally arranged theoretical blueprint of the target design later in the book. Focusing on the Vertical Technological Pillars (VTPs) in the first place, one could, in fact, enumerate four major components of relevance, the first three of which, spatio-temporal processing (STP), cooperative relaying (COR), and routing mechanisms (RMEs), are going to be placed altogether against the background of the fourth one, the so-called Autonomic Routines (ARs). The structure created in this way is intended to prepare the ground for the further analysis and introduction of the concepts to be gradually proposed, creating clear boundaries delimiting their scope and area of application. At the same time, the novel aspects will be introduced as the plot develops, including the Horizontal Architectural Extensions (HAEs) and the incremental conceptual outline.

As shown in Figure 2.14, the leftmost pillar of STP is described first to reflect the composition of the Open Systems Interconnection Reference Model, assuming a bottom-up traversal of the specific layers. Belonging to the physical layer (PHY), STP provides the very desirable capability of radio channel orthogonalisation, allowing for immediate improvement of wireless transmission performance, especially in terms of data transfer reliability. In fact, the name of spatio-temporal processing has not been chosen accidentally, as the specific technique, space-time block coding (STBC), employed in the analysis throughout this book, is claimed to be much more of a modulation-driven than a coding-based approach (Alamouti, 1998). This is so since, by contrast with space-time trellis coding (STTC), no coding gain (CG) may be achieved in the former case, yet the highly relevant diversity gain (DG), to be discussed in more detail at a later stage, is still observable. Space-time block coding has been chosen as the most representative approach to STP given the nature of the overall concept under discussion. It can obviously be replaced with other, more complicated, techniques offering even better performance, yet given the overall complexity of the ultimate Autonomic Cooperative Networking Architectural Model, it became of prime importance to keep all the building blocks reasonably balanced, still allowing for their being advanced, should this turn out necessary.

Most importantly, however, irrespective of the approach to STP employed, the utmost emphasis will be laid on the realism of the proposed solution, especially given the fact that STBC will not be applied between or among fixed elements of a multi-element array (MEA), which would fairly naturally reflect the most relevant environment this technique was specifically designed for, but, rather, it will be exercised by a dynamic set of mobile relay nodes (MRNs), simply referred to at this stage as relay nodes (RNs). For this reason, the question of proper maintenance of synchronism needs to be understood in a comprehensive way, requiring not only the higher-level perspective to be taken into account, where it is the network layer protocol orchestrating the behaviour of specific relay nodes, but also requiring the focus to be shifted to the link layer (LNK), where orthogonal frequency-division multiple access (OFDMA) to the cooperatively shared radio transmission medium may be successfully incorporated into the global picture of the whole design (Wódczak, 2012). Thus the rationale behind the cyclic prefix (CPX) inherent in orthogonal frequency-division multiplexing (OFDM) becomes of critical relevance, as it may perfectly serve its purpose when the fine-tuning portion of synchronisation provisioning is exercised at the physical layer, similarly to the manner in which it is performed in the case of Digital Terrestrial Video Broadcasting (DVB-T) systems (Gonzalez-Bayon et al., 2010). One should note, however, that despite being mentioned here, a more profound investigation of the issue of synchronism remains beyond the scope of this book.

Moving forward to the pillar of cooperative relaying immediately shifts the overall context of the discussion to the link layer, where also the medium access control (MAC) sublayer is located, as explained, for example, by Tanenbaum and Wetherall (2011). In fact, the MAC-related region of interest has already been touched upon, although it happened in a rather indirect way: OFDMA, mentioned in the previous paragraph, undoubtedly qualifies as belonging to its set of inherent protocols. On the other hand, however, it clearly contrasts with OFDM since the latter belongs directly to the physical layer given its pure characteristics of a modulation-type technique. In the light of such slight differences in terms of nomenclature and their reciprocally significant discrepancies in technical meaning, there is no wonder that in spite of stemming from STBC, the concept of distributed space-time block coding (DSTBC), which is yet to play a key role in the conceived solution, should be assigned to the link layer, too. Such an allocation is conditioned by the fact that DSTBC, as introduced by Laneman and Wornell (2003), is already more of a mapping of the legacy STBC onto a networked setup, yet without involving any network layer routines per se. This is so, even though it is fairly usual to perceive DSTBC as a cooperative relaying protocol, while the notion of a protocol should be understood in a different way in this context, since its semantic field leans more towards a typical link layer mode of operation.

Even though DSTBC may be perceived to be the key element of the overall design, it is necessary to align it with the concept of virtual antenna arrays (VAAs), as outlined by Dohler et al. (2003), since usually the latter³⁷ will be referred to throughout the chapters to follow, while, in fact, the former will be meant. The reason for such a duality appears to be conditioned by a couple of factors. On the non-technical side, the introduction of the initial versions of both approaches appears to have coincided in time, at least to some extent, thereby making any rigidly definite distinction between them in terms of naming somewhat artificial, if not confusing or inadequate. On the technical side, VAAs are often claimed not to be limited to employing just the technique of STBC, thus elevating the DSTBC approach to the status of a special mode of operation, which, at the same time, seemingly creates the most desirable compromise in this respect, also fully respected throughout this book. One should note, however, that despite the said mode of operation, the relay nodes supposed to form a VAA need to employ one of the yet to be discussed cooperative relaying protocols, commonly known under the names of amplify-and-forward (AF), decode-and-forward (DF), and decode-and-reencode (DR), to ensure that the data conveyed in a wireless manner from a given source node (SN) to the relevant destination node (DN) will be properly relayed.

Last, but not least, among the three major pillars are the routing mechanisms so necessary for orchestrating the system behaviour from the yet more elevated viewpoint of the network layer. In fact, the cooperative relaying protocols mentioned in the previous paragraph are predominantly part of the link layer since, as much as they can cover local interactions among adjacent relay nodes, for pragmatically justified reasons they are not designed to scale up too extensively, and, therefore, are also not ready to serve communication between disjoint cooperative groups. One should note, however, that by no means should such a characteristic be perceived as a deficiency, since any related limitation is clearly imposed by the scope of operation attributable to the link layer, thereby allowing for the proper functioning of such protocols on a small scale, yet being far away from what is meant to be delivered by a fully-fledged routing scheme. This is, in fact, where the routing mechanisms come into the global picture of the solution to be presented; they are, additionally, carefully chosen to address the requirements imposed by a setup originating from and following the nature of mobile ad hoc networks. In particular, the Optimised Link State Routing (OLSR) protocol is going to be employed, not only because of the fact that it belongs to the so-called proactive class, which is characterised by continuous and periodic dissemination and collection of control data, but especially thanks to its innate mechanism of multi-point relay (MPR) station selection heuristics found by the author to perfectly integrate with VAA-driven cooperation (Wódczak, 2007).

As such, the above-mentioned MPR station selection heuristics allows for an immediate upgrade of the workings, and therefore also a related improvement in performance and reliability, of the underlaying cooperative relaying protocol operating at the link layer, chiefly because of the fact that additional information of a much wider scope becomes instantly available, allowing for much more accurate preselection of the relay nodes to be assigned to their most relevant VAAs. At a later stage, as the plot develops even more comprehensively, it is expected to become highly conspicuous that the enhancement of accuracy may be obtained virtually at adjustably diminishable additional cost in terms of the incurred control overhead of the respectively modified Optimised Link State Routing protocol, as well as with the possibility of maintaining, in most cases, full backward compatibility thereof. The network layer would seem to be the highest extent to which one could traverse in an attempt at providing the fullest attainable cooperative networked system automation, should it not be for the slightly separately positioned fourth pillar, the so-called Autonomic Routines. As such, this pillar will not be addressed too extensively at this stage, not only because a significant part of this chapter has already been devoted to the description of its workings, but especially due to the fact that its advantages will gradually unfold with every paragraph to follow. It will become especially visible in next subsection, where the Horizontal Architectural Extensions will be presented in the context of the VTPs.

In order to summarise this part, as well as provide a proper background for the upcoming developments, certain high-level pieces of information will be delivered in the form of a conclusion, so that a comprehensively consistent picture of the overall design may be fully outlined. In essence, even though the idea of the Autonomic Cooperative Networking Architectural Model derives directly from the conceptual assumptions behind the discovery of the legacy autonomic computing, the Horizontal Architectural Extensions will expand upon the most up-to-date instantiation of autonomic computing in the form of the Generic Autonomic Network Architecture, where all the workings of the former are well adjusted to the nowadays prevailing approaches in this respect. For this reason, the entire design will be somewhat driven by the emerging interrelationship between the layered structure following the well-known pattern of the Open Systems Interconnection Reference Model and the levels of abstraction inherent in the Generic Autonomic Network Architecture. As a result, all the carefully and specifically drafted decision elements belonging to the said levels of abstraction will be allowed to orchestrate the behaviour of their pertinent protocol-like entities allocated to the most relevant region of the said Open Systems Interconnection Reference Model. Most obviously, such a manner of operation will be tightly monitored and overseen thanks to the deployment of the already introduced hierarchical autonomic control loops. Consequently, an additional dimension will be incorporated into the workings of both the above-mentioned developments, so that it will become possible to further advance the state of the art in this area of science.

2.4.2 Horizontal Architectural Extensions

Given the background and context of the VTPs, the time has come to present the Horizontal Architectural Extensions (HAEs) along with the related design challenges in order to pave the ground for the ultimate incremental conceptual outline. In fact, as already mentioned, the naming pattern adopted in this respect by the author has not been chosen accidentally, but with clearly identified objectives that go well beyond pure linguistics. To some extent at the expense of the Open Systems Interconnection Reference Model, normally orientated in the bottom-up direction, it has become possible to expand the concept of the Autonomic Cooperative Networking Architectural Model by building on top of each of the VTPs, even though their modified left-to-right arrangement shown in Figure 2.14 might not appear to be immediately and fully understandable for reasons stemming from conceptual convictions. Thanks to such an approach, though, it will be possible to use two-dimensional drawings for the sake of expressing the rationale behind the three-dimensional architectural advancements to be presented across this book. This will be achieved not only by applying the conceptual expansion of the pillars in the upward direction, where normally other layers belonging to the Open Systems Interconnection Reference Model would be drawn, but also through exercising the possibility of spanning the said extensions, as inspired by the workings of the Generic Autonomic Network Architecture, over the adjacent technological pillars and beyond.

While this approach, consisting in the expansion of the concept in the bottom-up direction upon the vertically orientated technological pillars as explained above, is necessary for the sake of making the layers of the Open Systems Interconnection Reference Model and the levels of the Generic Autonomic Network Architecture mutually orthogonal, the possibility of spanning the Horizontal Architectural Extensions over the adjacent pillars and beyond becomes critically necessary because of the need to accommodate all the related cross-layer enhancements. Thus, assuming the perspective presented in Figure 2.15, one may enumerate four extensions arranged in an incremental order: the first three, the Autonomic Cooperative Node (ACN), Autonomic Cooperative Behaviour (ACB), and Autonomic Cooperative Networking Protocol (ACNP), are presented as belonging to one group; the fourth, in the form of the Autonomic Cooperative Networking Architectural Model, is chosen to provide the synergetic background spanning the former three. It is little wonder that both the VTPs and the HAEs contain the same number of elements arranged in a fairly similar manner, i.e. three of them grouped together in each case with the fourth taking an elevated position. While such elevated elements of both classifications appear to glue together without doubt, it will turn out shortly that the others overlap thematically, too. This results not only from the assumed orthogonality, but also from building the extensions on top of their respective pillars.

In order to shed more light on the aforementioned extensions, and to emphasise the potential complexity of the related transition in terms of providing a comprehensive mapping, each of the cases will be discussed on a rather high level, before a much more in-depth analysis is to be carried out in the following chapters. In fact, looking at the first pair of components, encompassing both STP and ACN, as depicted in Figure 2.16, one may discern immediately that while the former component appears to be rather strictly narrowed down when the semantic perspective is concerned, the latter seems much more capacious, especially since its ultimate definition has not yet been put forward. Interestingly, even though both components appear to be nouns, STP falls into the category of a gerund, while the ACN is more of a proper noun, making the explanatory process much more demanding at the level of nomenclature. The explanation of such a discrepancy is in the assumed flexibility allowing the architectural extensions to span over adjacent technological pillars, which is definitely true in the analysed example. In other words, in the case of the technological pillars it became fairly straightforward to distinguish between STBC and DSTBC by simply assigning them to the physical layer and link layer, respectively. At the same time, the Autonomic Cooperative Node is assumed to cover both those areas, and even go well beyond them.

In fact, looking more broadly, one could claim that certain parts of STP seem to fall more into the category of Autonomic Cooperative Behaviour, as shown in Figure 2.17, where the originally expected transition would apparently originate from cooperative relaying. In order to account for such a situation, it could be helpful to assume that the notion of an Autonomic Cooperative Node would rather stem from a legacy relay node exposing an inclination towards Autonomic Cooperative Behaviour by being characterised by a set of accompanying cooperative capabilities manifesting themselves through the ability to become part of a VAA performing the operation of distributed space-time block coding. In other words, the transition in question from STP to ACN would need to be defined through the inclusion of cooperative relaying, while the more obvious one from cooperative relaying to Autonomic Cooperative Behaviour could be further justified with the aid of STP. Moreover, the Autonomic Cooperative Node could not even be limited to spanning just the bottom two adjacent pillars; as will be shown, it will rather remain in close relation to all of them, while, at the same time, it will play its most fundamental role as an element of a VAA in order to exercise cooperative relaying. This is exactly why all the transitions under investigation have been purposely presented in separate figures, as what could initially seem to be a fairly straightforward operation of simple mapping immediately highlights the challenges ahead of the overall design to be described.

To unintentionally complicate things even further, yet still leaving all the details to be revealed at the appropriate time, the reader should note that the already discussed Autonomic Cooperative Behaviour would not be sufficiently comprehensive, should it not encompass, at least to some extent, the multi-point relay station selection heuristics of the Optimised Link State Routing protocol, introduced previously with the VTPs. Such an assumption becomes interestingly important, as it implies that certain parts of the Optimised Link State Routing protocol are to be redefined when the Autonomic Cooperative Networking Architectural Model is outlined, especially because, according to Figure 2.18, it might be expected that the multi-point relay station selection heuristics should remain a key part of the Autonomic Cooperative Networking Protocol. Most obviously, even if such a modification is advocated for architectural reasons, the overall functionality of the modified Optimised Link State Routing protocol should not become inferior when compared to its original version. Quite the contrary: the modular approach of the proposed type may only improve the overall system stability and scalability, especially given the fact that additional developments stemming from and conditioned on the Generic Autonomic Network Architecture are to be incorporated, for example appropriately designed decision elements along with their respective hierarchical autonomic control loops, to provide a fully-fledged and self-sustainable solution in the form of the Autonomic Cooperative Networking Architectural Model.

Finally, the last transition is expected to pertain to the relation between the Autonomic Routines and the Autonomic Cooperative Networking Architectural Model, where the focus is much more shifted to the extraction of the relevant workings of the Generic Autonomic Network Architecture and to the provision of newly designed decision elements entering into mutual relations in both the vertical and horizontal directions, predominantly over their respective hierarchical autonomic control loops. This transition appears to be the most complicated, given the number of elements involved, but since at this stage of design not too much relevant information has been disclosed for practical reasons, it is not really possible to present a similarly high-level discussion of the sort exercised for the other extensions. Taking into account the background nature of the Autonomic Cooperative Networking Architectural Model, one may foresee that its elements will undoubtedly be present in virtually every aspect of the eventual design, including not only all of the components of Autonomic Cooperative Node, Autonomic Cooperative Behaviour, and Autonomic Cooperative Networking Protocol, but also the architectural overlay formed by itself. In such a context, based on the ground-setting VTPs, as well as taking into account the HAEs, the ultimate incremental conceptual outline will be provided in the next subsection. In this way the first, introductory, part of this book will be considered to have been completed and the focus will move to a discussion of the specific components of the target design.

2.4.3 Incremental Conceptual Outline

The Autonomic Cooperative Networking Architectural Model under construction in this book is assumed to be based, on the one hand, on an incremental theoretical design of the relevant architectural components, which, on the other hand, whenever applicable, will be additionally evaluated and validated in an experimental manner with the aid of computer-assisted simulation. In particular, given the general frames of the Autonomic Cooperative Networking Architectural Model introduced thus far, the crucial architectural components of Autonomic Cooperative Node, Autonomic Cooperative Behaviour, and Autonomic Cooperative Networking Protocol are going to be defined in the sense of outlining their respective scope of operation and mutually dependent roles, so that it is possible to devise matching decision elements to take full responsibility for orchestrating them. To this end, the aforementioned dual perspective will be exercised where, on the Open Systems Interconnection Reference Model side, special emphasis will be placed on the physical layer, the link layer, and the network layer, while on the Generic Autonomic Network Architecture side similarly increased attention will be paid to the protocol level, the function level, the node level, and the network level. In this way the previously made assumption will be satisfied, according to which the analysis and design effort has been arranged in accordance with two orthogonal collocated axes in the form of the VTPs and HAEs. At the same time, additional architectural components will be incorporated into the blueprint in order to progress further towards making it even more concrete.

In fact, looking at the more detailed outline provided in Figure 2.19, one may discern a number of hierarchical relations driving the Autonomic Cooperative Networking Architectural Model, purposely presented in a way that does not involve any notion of the Open Systems Interconnection Reference Model. In particular, the overall drawing should really be analysed in the third dimension by placing special emphasis on the component of depth, chosen to be represented in the bottom-up direction in such a way that the smallest architectural entities, visible as Autonomic Cooperative Nodes, should be perceived as if they were located closer to the spectator, while the biggest one, manifesting itself as the Autonomic Cooperative Networking Architectural Model, would play the role of an umbrella-like overlay, binding all the other entities tightly together.³⁸ Going this way, one may conclude immediately that as much as in the previous subsection it was necessary to account for Autonomic Cooperative Behaviour rather indirectly, with the aid of the notion of VAAs stemming from the VTPs, it now becomes possible to perceive Autonomic Cooperative Nodes as members of autonomic cooperative sets (ACSs) inherent in the physical layer and, possibly, also the link layer, thereby somewhat detaching the more elevated and conceptual Autonomic Cooperative Behaviour from the lower layers of the Open Systems Interconnection Reference Model. In other words, when exercising cooperative relaying, the Autonomic Cooperative Nodes would always express Autonomic Cooperative Behaviour, yet such a notion would be reserved much more for the needs of the network layer.

Before a more detailed overview of the Autonomic Cooperative Networking Architectural Model can be provided, building on what is already known of its general workings, it appears crucial to sketch the conceptual relation between the Generic Autonomic Network Architecture, the proposed architectural concept it directly stems from, and the Open Systems Interconnection Reference Model it is intended to interact with. In fact, following what has already been described, and what can be seen in Figure 2.20, the mutual orientation of the Open Systems Interconnection Reference Model and the Generic Autonomic Network Architecture tends to be perpendicular, if not, using the language of mathematics, orthogonal. In fact, given the complexity of the interaction in question, any analogy with orthogonality could possibly hold true, as far as the notion of a geometrical ‘right angle’ is concerned, yet by no means should it approach the connotation of ‘statistical independence’. As the vertically orientated layers are put against the horizontally arranged levels, the additional notion of the related decision elements is brought into the overall picture with the intention of highlighting their supervisory nature vested in them for the sake of becoming responsible for overseeing the entire setup under the umbrella of the Autonomic Cooperative Networking Architectural Model. However, for design-related reasons, the architectural entities stemming from various levels will need to be directly mapped onto specific layers, while the arrangement of decision elements, forming a reversed trapezoid, will occupy the top-most part thereof.

Such an arrangement is presented in Figure 2.21, where the aforementioned generalities of the Open Systems Interconnection Reference Model and the Generic Autonomic Network Architecture are replaced with the much more specific workings of the target Autonomic Cooperative Networking Architectural Model. To this end a fragmentary, vertically rearranged, protocol stack is employed consisting of the three lowest layers of the Open Systems Interconnection Reference Model. Even though such a reduction could make the resulting stack, in certain sense, appear to lean towards the one advocated by the TCP/IP protocol suite, as described by Tanenbaum and Wetherall (2011), it should by no means be perceived in such a way. What is more, keeping the above context in mind and changing the viewpoint slightly towards the decision-making logic located on top of the overall arrangement in question, defined directly on the grounds of the architectural principles advocated by the Generic Autonomic Network Architecture, one may discern that each of the four levels of abstraction contains the corresponding decision elements reflecting the requirements imposed by the Autonomic Cooperative Networking Architectural Model. In particular, maintaining the bottom-up direction for consistency reasons, one may enumerate the following entities: cooperative transmission decision element (CTDE), cooperative re-routing decision element (CRDE), cooperation management decision element (CMDE), and cooperation orchestration decision element (CODE), all positioned in a manner allowing for unhindered interaction with any entity available.³⁹

In fact, commencing the description with the physical layer, the yet to be introduced entity of the equivalent virtual multiple-input multiple-output (EVMIMO) radio channel should be perceived as remaining in immediate functional correspondence with its related counterpart responsible for distributed space-time block coding and located at the link layer. Such an approach makes the resulting tandem jointly constitute what is referred to as the autonomic cooperative set (ACS), intended to serve, at least to certain extent, as an elevated incarnation of the previously briefly characterised source concept of VAAs, detailed by Dohler and Li (2010). In essence, such VAAs are composed of relay nodes whose role is to act cooperatively in order to preprocess the transmitted signals in accordance with a given STBC matrix in a distributed manner, yet without any support on the side of network layer routines. As such, the ACS, in the form of an architectural entity, additionally spans the multi-point relay station selection heuristics of the Optimised Link State Routing protocol so that it is possible to establish an even more comprehensive notion of the Autonomic Cooperative Behaviour. Thus, the Autonomic Cooperative Behaviour should be perceived as a more elevated form of the aforementioned ACS, mostly because it is predestined to combine the pertinent routines of all three layers of the Open Systems Interconnection Reference Model. What follows is the Autonomic Cooperative Networking Protocol, which builds upon the Optimised Link State Routing protocol, yet extracts certain parts to instantiate the ultimate notion of Autonomic Cooperative Behaviour.

Last, but not least, come the above-mentioned decision elements stemming directly from the Generic Autonomic Network Architecture and fully meeting the design principles it prescribes, while having been defined exclusively for the needs of the proposed Autonomic Cooperative Networking Architectural Model, quite similarly to the various other architectural components introduced in their evolved forms under the umbrella of the Open Systems Interconnection Reference Model. Taking into account that there are three layers of the Open Systems Interconnection Reference Model involved, as opposed to the four levels of the Generic Autonomic Network Architecture intended to interact with them, one may most naturally expect that there is not a one-to-one correspondence in this respect. In particular, in the bottom-up direction typically followed in this book, first comes the CTDE, to be responsible for the establishment of DSTBC with the involvement of both the physical layer and the link layer. Immediately to follow is the CRDE, responsible for the management of the cooperative re-routing (CRR) functionality. Next appears the CMDE, chiefly visible at the network layer and accountable for the coordination of the related cooperative transmissions and noncooperative transmissions, respectively. Finally, the globally distributed Autonomic Cooperative Behaviour is to be overseen by the CODE, covering, and often going well beyond, the network layer.