6.2.1 Research and Investment Perspective

Looking back already from a little bit historical perspective, it transpires that ever since the role of standardisation in the realm of the future internet (FI) has started growing more and more profoundly, the related need for consensus became sought after not only by various related research-driven, but also investment-orientated parties thereto. The ever increasing and substantial interest in this respect may be, most likely, attributed to the fact that the reference to the notion of the ‘future’ in the very name thereof, makes it appear to be continually evolving in an open-ended manner, thereby, definition-wise, possible to be captured at certain time instances only, but rather not in general. What is more, aside from such evolutionary development, one could also assume an even wider perspective, where more innovative, or even disruptive, approaches permanently stimulate continuous conception of a wide variety of different incarnations of the future internet in parallel. As much as there is little wonder that such a situation may be attributable to today's highly competitive market of new technologies, there also appears to exist a substantial stimulus thereto, especially given the fact that the foreseen number of devices to be interconnected worldwide is expected to grow even more drastically than ever planned. Such a context is directly pertinent to one of the said incarnations, in the form of the Generic Autonomic Network Architecture, advocating virtually full self-manageability of the future internet. Given the above mood, following the mutual relations among the stages of research, standardisation, and investment, are going to be analysed in the first place. Based on this, the specifics of the Generic Autonomic Network Architecture case will be scrutinised and the standardisation ecosystem will be reviewed.

The major effort in the standardisation of the Generic Autonomic Network Architecture was undertaken by the Industry Specification Group (ISG) on Autonomic network engineering for the self-managing Future Internet (AFI) functioning under the auspices of the European Telecommunications Standards Institute (ETSI), as outlined by Chaparadza et al. (2009a).¹ In fact, the ETSI ISG AFI was established in response to a commonly prevailing consensus across industry and academia that the prior developments and conceptual works, as well as numerous follow-up efforts materialising at that very time, which, otherwise, should have been progressing as a joint effort, were, in fact, advanced, but rather separately, if not competitively, despite the very identical objective of achieving a comprehensive architectural design for the emerging concept of autonomic networking. For that reason, keeping in mind the history of the known standardisation deficiencies related to the Open Systems Interconnection Reference Model, a relevantly urgent harmonisation was required, especially given the rapid progress in the realm of the future internet, as indicated by Wódczak et al. (2011). In fact, the historical perspective seems to have played a key role in this respect, as the process of standardisation of new concepts cannot be done effectively and efficiently if detached from the technology and business-related background, as explained by Tanenbaum and Wetherall (2011). In other words, it may be claimed that, aside from standardisation per se, it is also necessary to take into account the phases of research and investment, acting as triggers for and delimiters of the entire process.

In fact, by no means should the above-mentioned explanation by Tanenbaum and Wetherall (2011), also known as ‘the apocalypse of two elephants’, be considered a mere claim. Essentially, there exists conspicuous and ‘living’ proof in the form of the Open Systems Interconnection Reference Model, since the standardisation cycle of its protocol stack was obstructed by certain factors, such as wrong timing, inadequate technology, unsatisfactory implementations, and impaired politics (Tanenbaum and Wetherall, 2011). Consequently, the OSI RM was prepared before the actual protocols were devised, quite the contrary to TCP/IP, where the protocols were delivered first, while the Reference Model simply served as their description. It then becomes clear that the research phase is inevitable in the standardisation scenario, yet proper timing is maybe even more important. As can be seen in Figure 6.1, should the related standards be rolled out prior to the research phase, the resulting specifications would be likely to remain immature. If the opposite held true, where the specifications are published with too great a delay, the market would be unlikely to wait and so investments in proprietary solutions could prevail, resulting in a lack of orchestration. Nowadays, although it may still be necessary to arrange for the proper timing, the level of awareness of the parties involved appears to have become sufficiently high, given the lessons learned in the past. Nonetheless, taking into account the scale of investment needed, it similarly became of prime importance for the standardisation² of autonomic networking to be agreed upon properly.

In the light of the above background and reasoning, it was decided that the structure of the ETSI ISG AFI be arranged according to specific Work Items (WIs), intended to form the basis for the preparation and publication of the relevant Group Specifications (GSs), at the same time keeping the option of having them upgraded to Technical Specifications (TSs) once the effort has matured even further, as outlined by Wódczak et al. (2011).³ Consequently, from a time perspective, it is possible to emphasise that the standardisation work of the ETSI ISG AFI resulted in the finalisation of two preparatory WIs, so that the scenarios, use cases, and requirements for autonomic and self-managing future internet were outlined in the ETSI-GS-AFI-001 (2011) GS, while the aforementioned architectural reference model for autonomic networking, cognitive networking, and self-management as required by autonomic network engineering for the self-managing future internet was defined in the ETSI-GS-AFI-002 (2013) GS. Following the completion of these WIs, the emphasis moved to the standardisation process in the area of autonomic reference architectures, analysis of requirements, and specification of implementation-orientated solutions (Wódczak et al. 2011). To this end, the third WI was created and initially subdivided into four complementary branches with the following scopes and naming patterns: ‘Autonomicity-enabled NGN Reference Architecture (Fixed/Wired Networks)’, ‘Autonomicity-enabled Broadband Forum (BBF) Reference Architecture’, ‘Autonomicity-enabled Mobile Network Architecture (3GPP and Non-3GPP)’, and ‘Autonomicity-enabled Wireless Ad-Hoc/Mesh/Sensor Network Architecture’.

As the standardisation effort carried out by the ETSI ISG AFI started becoming more and more widespread, the body agreed to openly establish a methodology consisting of an outer and inner process, as outlined by Wódczak et al. (2011). In particular, as depicted in Figure 6.2, the overall outer process became based on the assumption that input from research and development projects would be invited not only to contribute to the refinement of the Generic Autonomic Network Architecture itself, but also to the update of the operator requirements, use cases, and scenarios. At the same time, a very tight interaction between the two WIs related to those branches was encouraged, so that the ultimate implementable architectural model could be devised as the major, and most comprehensive, outcome. Similarly, the inner process, as depicted in Figure 6.3, would be based on the implementing interaction between the two initial WIs, and, then, feeding the output directly to the third WI, yet, as the process would be iterative, feedback from the latter could be also conveyed to both the former WIs. Moreover, in addition to both the above-mentioned inner and outer processes, as depicted in Figure 6.4, thanks to specific liaisons outside ETSI, the ISG AFI was to become part of a wider ecosystem including organisations such as 3rd Generation Partnership Project (3GPP), Telemanagement Forum (TMF), International Telecommunication Union – Telecommunications (ITU-T), Internet Engineering Task Force (IETF), European Union (EU) Framework Programme (FP), Broadband Forum (BBF), and Next Generation Mobile Networks (NGMN) (Wódczak et al. 2011).

6.2.2 Staged Instantiation of Reference Model

Looking at the ecosystem and the profiles of the organisations identified therein, one may come to the conclusion that, comprehensive as it may be, when analysed from the conceptual design perspective, the rationale behind the intrinsic arrangement driving the workings of the Generic Autonomic Network Architecture appears not to have been devised accidentally, since it is ready to cover a vast range of potentially compliant systems, requiring the incorporation of an autonomic overlay (AO) to enable virtually ubiquitous self-management. In particular, being generally targeted at the orchestration of vastly distributed networked systems, the Generic Autonomic Network Architecture is inherently based on the four conceptual levels of abstraction in the form of the protocol level, function level, node level, and network level, listed in the bottom-up order. A structure of this type, allowing to take direct control over any pertinent physical software or hardware components at the lowest level of the hierarchy only, while, in the majority of cases, making the entities located above responsible for the encapsulation of certain logic resulting in improved general flexibility in terms of the internal structure and the roles taken, is highly pertinent to the staged instantiation of the Reference Model behind the Generic Autonomic Network Architecture. Such an approach may be contemplated thanks to certain design assumptions, according to which the interrelated functional blocks (FBs) were introduced along with their respective reference points (RFPs). Interestingly, being arranged in a staged manner, this orchestration is supposed to proceed in a top–bottom order, as detailed below.

In general, the rationale behind the introduction of the Reference Model for the already outlined Generic Autonomic Network Architecture, as originally proposed by Chaparadza (2008) and, then, additionally advanced by Wódczak et al. (2011), is primarily related to the necessity of outlining the fully-fledged workings of the Autonomic Cooperative Networking Architectural Model, the ultimate version of which is to be further detailed in this chapter. One should note that, as such, the pertinent version of the existing GANA Reference Architecture would result not only from the European Union Seventh Framework Programme Integrated Project: Exposing the Features in IP version Six protocols that can be exploited/extended for the purposes of designing/building Autonomic Networks and Services (EFIPSANS), but especially from the follow-up standardisation effort carried out under the auspices of the European Telecommunications Standards Institute, and the Industry Specification Group on Autonomic network engineering for the self-managing Future Internet, in particular. To follow the original nomenclature introduced still in the past century and applied by Zimmermann (1980) to Open Systems Interconnection Reference Model, the notion of a Reference Architecture should be understood as a an incarnation, or maybe even an implementation of the said Reference Model. However, as the acronym of Generic Autonomic Network Architecture already contains the word ‘Architecture’, which makes the modifier of a Reference Architecture (RA) at least redundant, if not tautological, the author of this book would advise, for the sake of clarity, the usage either of the ‘GANA Reference Architecture’ or simply the ‘Generic Autonomic Network Architecture’.

According to the ETSI-GS-AFI-001 (2011) and ETSI-GS-AFI-002 (2013) GSs, the instantiation of the Reference Model for the Generic Autonomic Network Architecture may be perceived from the perspective of introducing the interrelated functional blocks and their respective reference points, both for its own internal needs and in order to enable open interaction with architectures defined by other standards development organisations (SDOs), such as the 3GPP or BBF. Given the complexity of such a process, a staged introduction of the components was prescribed in a top-down manner, starting from the knowledge plane, where the network level decision element normally resides, as depicted in Figure 6.5, through the node level outlined in Figure 6.6 and the function level presented in Figure 6.7, down to the protocol level contained in Figure 6.8. Not only does such an approach facilitate the overall instantiation process, but it also allows for proper coordination of autonomic functions (AFs) for the sake of stability provisioning. This requires that the hierarchical autonomic control loops be designed to guarantee noncoupling and nonconflicting behaviour of the said autonomic functions understood in a generic way, and by no means limited by mechanisms of time scaling or decision ordering, as outlined in the ETSI-GS-AFI-002 (2013) GS. As much as the hierarchical autonomic control loops condition any interaction between such autonomic functions, it is necessary to note the predominant role of mutual relations between decision elements, where a lower level decision element immediately becomes a managed entity.

Moving towards the internals of the Generic Autonomic Network Architecture, one should note that a generally holistic approach is advocated, where not only are distinct network nodes, in fact acting as autonomic nodes, supposed to express their respective, yet by default noncooperative, autonomic behaviour, but the overall distributed network is presumed to function in an entirely autonomic fashion. From such a perspective, it already appears clear that, even if cooperation were not precisely defined, it could undoubtedly be one of the most inherent features of such an autonomic networking system, where otherwise diminishable and simple information exchange might have a really constructive, and therefore cooperatively positive, influence on the overall system functioning. This might seem even more obvious when the assumption of the underlying biological connotation of self-management is kept in mind, according to which such an autonomic networking system would be expected to imitate the behaviour of a living organism, and particularly the behaviour of the human autonomic nervous system in terms of being continually driven by a substantial number of parallel processes, operating on their own yet still remaining in close correlation, making it possible to continually avoid any specific requirement for orchestration from a centrally positioned supervisory entity for the majority of the time of operation. To this end, it is claimed that such an autonomic networking system should monitor itself with the aid of hierarchical autonomic control loops running at different pace and located in the various levels of abstraction.

6.2.3 Cross-Specification Extensions

Given the increasing complexity of the currently devised networked systems of the future, one may come across other standardisation activities, possibly being carried out in a separate or not explicitly integrated manner, which are similarly progressing with intentions highly synergetic with autonomics. One could then consider certain cross-specification-related investigations, keeping in mind the ultimate objective of releasing the human mind from the supervision of the related configuration and management processes to the highest possible extent, thereby also attempting to increase the overall stability and scalability of such advanced designs, as indicated by Wódczak (2014a). Being realistic, and taking into account the previously described role and pattern of a properly arranged standardisation cycle, one might become hesitant with regard to any possibility of a fully structured approach in this respect, until it becomes apparent that the institution of liaison could be highly useful in this respect. Regardless of any such uncertainties, the author would like to explore briefly a few areas of related standardisation efforts, where autonomics could benefit the other design, the other design could benefit autonomics, or, best of all, the two could capitalise on each other. As outlined in Figure 6.9, three different options are addressed below under the assumption that not all of them must be standardised by the same SDO. First comes software-defined networking (SDN), then machine-to-machine (M2M) communications, and finally intelligent transport systems (ITSs).

In particular, by no accident is the rationale behind the programmability driven concept of software defined networking (SDN)⁴ to be discussed prior to the other two approaches, as this one seems a little bit elevated making it to be fairly on par with the related routines of Generic Autonomic Network Architecture, just to consider Chaparadza et al. (2013). Even though the logic is different, the justification remains similar, as it stems from the fact that the distributed character of today's networked systems demands certain dose of facilitation in terms of their configurability and manageability. One should note, however, that, by comparison, the need for autonomics corresponds to the fact that even nowadays the more and more sophisticated policies and tasks might still demand implementation with the use of a legacy command line interface (CLI), which, in fact, allows for the use of a limited set of low-level device configuration directives only, as explained by Hyojoon and Feamster (2013). Apparently, still a while ago, such an issue did seem resolvable with the aid of the so-called dynamic scripting techniques, yet, as of now, even assuming that one could perform the entire configuration in such a way, the technological progress and the changing state of the continually evolving networked systems, would render a proper maintenance thereof virtually impossible (Wódczak, 2014a). This is why, among others, the concept of SDN assumes that the network behaviour be rather managed through a set of specifically designed interfaces, as indicated by Haleplidis et al. (2015). While one's perception could be that this might remove a certain amount of leeway, in practice a great configuration relief should be expected instead.

There is no denying that the concept of SDN has been emerging for quite some time to finally gain an unprecedentedly rapid growth of interest (Wódczak, 2014a). Looking into the details, this approach assumes that the data plane and the control plane (CTP) be separated in the current understanding, as indicated by Hyojoon and Feamster (2013). In other words, the behaviour of the whole networked system is expected to be not only orchestrated but, in fact, dictated by a logically centralised yet physically distributed controller, intended to assume the role of a kind of system brain, operating within the control plane. At the same time, all the other network nodes are supposed to reduce their operation to packet forwarding devices of a basic nature, instead functioning within the data plane. Interesting though it may seem, the rationale behind such an understanding of SDN might at first appear not to be in line with the reasoning stemming from the Generic Autonomic Network Architecture. This perception may result from the somewhat inadequate understanding that while the Generic Autonomic Network Architecture advocates virtually ubiquitous automation, SDN promotes an approach where the control is taken from network inherent processes. In reality, however, both the concepts appear to lean towards more or less the same objective of allowing the network operator to impose certain directions on the underlying networked system, while the differences between the two seem to pertain to the extent to which they may exercise self-manageability.

As outlined by Wódczak (2014a), attempting to incorporate the routines of SDN into the Autonomic Cooperative Networking Architectural Model under discussion in this book, the functionality of the plain autonomic node would be proposed to be capped at the function level of the abstraction provided by the Generic Autonomic Network Architecture, which would relevantly restrict the Open Systems Interconnection Reference Model related capabilities, too. At the same time, it would be desirable that the respective functionality of the Autonomic Cooperative Node, intended to express Autonomic Cooperative Behaviour, offer fully-fledged coverage of the entire range of the levels of abstraction. In fact, the number of levels of abstraction would be subject to dynamic changes, since, once the promotion to the level of an Autonomic Cooperative Node took place, the functionality of autonomic networking would need to become elevated, as well as seamlessly reduced, should the conversion in the opposite direction hold true. Such a repositioning could be triggered by a dynamic network reconfiguration resulting, for instance, from externally imposed policies, or be conditioned by an internal event resulting from the willingness to carry and forward traffic. Given the above, one could see that the GANA and SDN benefit each other more or less equally, especially given that it is openly claimed that sometimes it could be necessary to open the hierarchical autonomic control loops of the former, while the latter already provides a readily available mechanism that could facilitate the injection of certain control data in the form of external policies, for example.

Shifting the focus more towards both machine-to-machine communications and intelligent transport systems,⁵ it appears that the role and position of the Generic Autonomic Network Architecture would be fairly different in this respect, especially due to the fact that in both cases configurations resembling the mobile ad hoc network scenarios would be of interest. In other words, rather than serving as a mutually complementary concept, the rationale behind the Generic Autonomic Network Architecture could be applied to orchestrate each of the two, thereby reflecting the primary design objective of the same to act as a self-management overlay for networked systems. Looking into the definition provided by the ETSI-TS-102-689 (2010) Technical Specification, the machine-to-machine communications shall be established between two or more entities, and shall be assumed to be organised essentially without any specific necessity for direct involvement on the side of a human. What is more, as the related machine-to-machine services are to automate the relevant decision-making and communication processes, the overall concept thereof immediately appears to be highly synergetic with the already explained paradigm of self-manageability, so that an approach resembling the operation of the human autonomic nervous system, inherent in the Generic Autonomic Network Architecture, could be applicable. Such a characteristics are especially important in the case of highly complex networked systems, where the network nodes could equally well be instantiated by machine-to-machine devices, and where automation would be the only way forward in terms of sustainable and durable system operation, as outlined by Wódczak (2014a).

While the notion of a machine-to-machine system becomes more and more integrated with the idea of the Internet of Things (IoT),⁶ as outlined in the ETSI-TR-103-375 (2016). Technical Report, despite the fact that the latter is still undergoing substantial efforts in terms of becoming ultimately defined, the initial understanding of the former called for its decomposition into two functional parts, the first covering both the machine-to-machine device and machine-to-machine gateway, while the second encompassing the machine-to-machine network (ETSI-TS-102-690, 2013). As much as typically such an M2M device would be expected to connect to the respective M2M network over an M2M gateway, a direct connection is not precluded, under the assumption that a proper capability is implemented. In the light of the above it appears that one could introduce a new notion of M2M cooperative gateways able to express not only Autonomic Cooperative Behaviour, but also their willingness to carry and forward traffic, as proposed by Wódczak (2014a). Such an approach would remain very much in line with the rationale behind the Autonomic Cooperative Networking Protocol discussed earlier in the book, especially that the said M2M cooperative gateways would be entitled to play the role of Autonomic Cooperative Nodes. Thus the M2M-driven design could be integrated into the Autonomic Cooperative Networking Architectural Model, where, depending on the nature of the M2M devices, certain elements of the discussed SDN extension could also apply.

Finally come the intelligent transport systems⁷ which, given the global drive for worldwide deployment of efficient vehicular systems, are becoming a substantial element of the discussed cross-standardisation ecosystem: certain cooperative awareness related efforts are currently being undertaken, just to follow the ETSI-TS-102-868-2 (2017) Technical Specification.⁸ Yet, going even further and assuming a broader perspective, one may notice that, on the one hand, certain advancement in regard to the theme of this book becomes conspicuous in the case of both the physical layer and link layer, where the emphasis is generally laid on the provision of wider bandwidth and lower transmission latency, as outlined by Li et al. (2012a). On the other hand, however, similarly following Li et al. (2012b), one cannot forget the related routines of the network layer, where the aspects of autonomic networking and cooperative routing seem to gain more attention than one would expect these days.⁹ Essentially, the very relevant question of self-management still appears to lack a proper answer, which would make it possible to understand how the vehicular network nodes could become elevated to Autonomic Cooperative Nodes and enabled to express Autonomic Cooperative Behaviour to be orchestrated by the Autonomic Cooperative Networking Protocol (Wódczak, 2011c). In fact, the incorporation of the relevant overlay routines may be facilitated through the integration with the Autonomic Cooperative Networking Architectural Model, which builds on top of the Generic Autonomic Network Architecture along with its inherent hierarchical autonomic control loops, as explained by Wódczak (2014a).

Looking into the details, as indicated by Wódczak (2014a), the basic approach could assume that the interaction with the decision elements of the Generic Autonomic Network Architecture is taking place at all the levels of abstraction, where the hierarchical autonomic control loops allow for the orchestration of their respective managed entities, implemented within the on-board unit (OBU). In fact, the OBU shall function as a networked device encompassing a whole composition of various protocols and manageable routines, altogether making it by no means perceivable as a single managed entity. What is more, similarly to network devices such as typical routers, the relevant portions of the Autonomic Cooperative Networking Architectural Model would need to be integrated into such an OBU in order to oversee its behaviour from the inside. In other words, moving across the levels of abstraction, the cars constituting a given vehicular ad hoc network (VANET) would act as Autonomic Cooperative Nodes and would be entitled to form autonomic cooperative sets (ACSs), thereby expressing Autonomic Cooperative Behaviour under the supervision of the Autonomic Cooperative Networking Protocol, in order to instantiate distributed space-time block coding enabled cooperative transmission over a virtual multiple-input multiple-output radio channel. All in all, as it is clearly visible, the order of presentation made it possible to commence the analysis with the highest-level SDN¹⁰ so that, going through the M2M communications positioned somewhere in the middle, one could approach the ITSs, where certain concepts devised in this book would match directly.¹¹

6.3.1 Emergency System Requirements

An emergency communications network (ECN) is formed by the first responders (FRs), or, in fact, by the communication equipment they carry around in the area of an incident, where mostly mobile ad hoc network system configurations are possible, even though there are certain semi-fixed or rather movable components such as the mobile emergency operations centre (MEOC) of a completely different purpose. A configuration of this type appears to make the emergency communications network a very relevant area for experimentation in terms of the application of the routines driving the Autonomic Cooperative Networking Architectural Model, as defined throughout this book. Essentially, as there is no denying that, simply because of the related highly dynamic topology changes creating an entirely mobile environment, where the network nodes embodied by the somewhat elevated chief first responders (CFRs) may be upgraded to offer the capability of fully-fledged Autonomic Cooperative Nodes, it should be possible to exercise Autonomic Cooperative Behaviour through the formation of ACSs. In other words, one may be entitled to employ the conceptual device of an equivalent distributed space-time block encoder (EDSTBE) between the preselected chief first responders, so that, being fed by a base station (BS) located on the roof of the vehicle acting as the mobile emergency operations centre, they could provide communication capability to the first responders in the field, as proposed by Wódczak (2012b). All the configurations considered in this respect are discussed in detail below, along with certain system requirements that need to be properly incorporated.

In general, the current advancements in the realm of novel infrastructure design for the emergency communications networks of the future appear to be critically demanding in terms of the technologies to be applied, as explained by Vassiliadis et al. (2010) and Calarco et al. (2010). This phenomenon is particularly visible in the mobile ad hoc network part of the system, where the devices carried by the first responders seek seamless and on-demand connectivity for radio transmissions requiring different quality of service (QoS) measures to be implemented (Wódczak, 2011b). Thus, the emergency communications network, formed mainly by the first responders operating in the area of an incident, seems to have become a very relevant field for the application of the concepts related to the Autonomic Cooperative Networking Architectural Model. This especially holds true for the clearly envisaged to be numerous, yet rather small in size, groups of first responders, as coordinated by their respective chief first responders (Wódczak, 2012b). According to the requirements resulting from the most typical mode of operation in such scenarios, these groups may be assumed to contain strictly from four to six first responders, which may immediately be translated into certain advantages and disadvantages when the network topology of preference is concerned, as indicated by Wódczak (2011d). In particular, this might equally well mean that multi-hop communications between the chief first responders and their first responders might not be preferred or even allowed, since the first responders would normally be expected to gather around their chief first responders, forming a star topology as presented in Figure 6.10.

Approaching the issue of the related requirements from a purely technical perspective, one may come to the conclusion that such a multi-hop¹² configuration cannot be entirely precluded, especially under the circumstances where a group might need to be spread much more apart, as outlined in Figure 6.11. What is more, the possibility of serving larger groups, or maybe even merging and splitting groups, of first responders might also need to be taken into consideration, at least theoretically, to understand and address the behaviour of the entire system should any of the above-mentioned options become a reality. Going even further, this might raise the very relevant question of how the transmission should be arranged so that the emergency communications network demonstrates increased resiliency to the dynamically fluctuating environment it is required to operate in, as noted by Wódczak (2011e). In principle, the incorporation of the routines of the Autonomic Cooperative Networking Architectural Model, especially characterised by the inclusion of Autonomic Cooperative Behaviour, appears to constitute what could be referred to as a proper approach (Wódczak, 2011a). Its applicability is directly visible in Figure 6.11, which depicts a group of first responders where each of the members is perceived as an Autonomic Cooperative Node and could equally well be qualified to join an ACS, thereby becoming entitled to instantiate Autonomic Cooperative Behaviour, not only through autonomic cooperative transmission, but also autonomic cooperative re-routing (ACRR), as indicated by Wódczak (2014a).

As already signalled, there is yet another dimension to the investigated case, since, from the orchestration perspective of the emergency communications network, in addition to the chief first responders and first responders, the system also needs to feature both the emergency operations centre (EOC) and the mobile emergency operations centres. While the former is always located at a single fixed position, the latter typically coincide with fully mobile and specifically designed vehicles, always being relocated to the area of an incident. One may thus envisage two distinct types of Autonomic Cooperative Behaviour between the Autonomic Cooperative Nodes, instantiated by the respective chief first responders, to be taken into consideration (Wódczak, 2011d). In the first place, it is most commonly assumed that the process of communication involving two different groups of first responders, coordinated by two distinct chief first responders, will be assisted by those chief first responder only, who do not communicate directly, but rather over the mobile emergency operations centre, as outlined in Figure 6.12. Such an assumption would potentially need to be relaxed, however, in order to accommodate the possibility of a lack of communication between one of the chief first responder and the mobile emergency operations centre. One would also need to consider another situation, particularly in the initial response phase, when various groups of first responders might already be in a given location along with their respective chief first responders, while the mobile emergency operations centre could still be on its way.¹³

What is more, for legacy reasons stemming from a consolidated management approach imposed by the inherent human hierarchy, it could be required that only a given chief first responder route the data stream coming from the mobile emergency operations centre towards a given group of first responder, as no other chief first responder should be superior to the said group in terms of duty pertinent relations. As understandable as this is, there are no clear arguments from the system design perspective against the establishment of a logical link over such a chief first responder positioned externally to this group of first responders, as long as such operation remained transparent to the functioning of the emergency communications network so that the hierarchy could be perceived as if nothing had changed. Analysing such a case even further, as depicted in the example provided in Figure 6.13, for various reasons such as external obstacles to radio transmission or maximum time of service with a fully charged battery, one of the chief first responders may not be able to communicate with their first responders. As proposed by Wódczak (2012b), the system could address this situation through autonomic switching to a backup mode, where another chief first responder would act as an entity supporting the communication with the mobile emergency operations centre. Although it is technically feasible, such an approach could, in some sense, violate the said requirements in this respect.¹⁴ In fact, there may be much more to it than the human hierarchy, as in emergency situations the responsibility must be clear and the persons involved should know exactly from where the orders are physically coming.

6.3.2 Autonomic Control Incorporation

The previously discussed issue related to the discrepancy between certain justified requirements and the technological approaches thereto may create a serious issue at the design stage. This is especially important when the related technologies are so advanced that they could easily solve any outstanding problem, yet, for reasons similar to the ones stated above, where being in command means the responsibility for direct physical coordination of all the related actions in the field, one cannot risk employing them. Clearly, it could be possible to contemplate certain complementary solutions, where schemes such as conventional relaying, understood in the sense depicted in Figure 4.2, could be deployed in order to allow for a given chief first responder to have the communication it originates supported fully consciously by another chief first responder of their choice. Yet, even if not susceptible to being charged with any violation in this respect, such an approach could still remain doubtful from the legal perspective. For such a reason, the cooperation-enabled approach advocated here focuses solely on the communication originating from the mobile emergency operations centre, as then none of the potential restrictions comes even close to being at risk of becoming classified as doubtful. Next, in the light of the above, first of all the rationale behind such a cooperative solution will be outlined in more detail, before it is possible to advance the analysis towards certain related interactions involving the mobile emergency operations centre and its chief first responders, so that, eventually, the focus may be shifted to the ACNAM-related considerations.

Moving into the details, an example approach where the communication between the mobile emergency operations centre and a given first responder is carried out with the assistance of an external chief first responder, in a way transparent to the system and not affecting the hierarchy, is presented in Figure 6.14. As outlined by Wódczak (2012b), taking into consideration that a given first responder might become exposed to fairly severe impairments induced by the radio channel, for example from obstacles to radio propagation or too big a distance towards their chief first responder, another chief first responder could step into such communication so that the diversity gain offered by the virtual multiple-input single-output radio channel could be efficiently exploited, as the target first responder would be served cooperatively by both the chief first responders in question. This would allow the application of DSTBC, since both the chief first responders would logically form a virtual antenna array and apply the related physical layer signal processing techniques in order to orthogonalise the wireless radio channel. Consequently, the data could be delivered in a more resilient manner, assuming that proper synchronisation can be guaranteed between the cooperating chief first responders. Essentially, shifting more towards the nomenclature inherent in the Autonomic Cooperative Networking Architectural Model, one could say that, as long as both the chief first responders are exposing the capabilities of and acting as Autonomic Cooperative Nodes, Autonomic Cooperative Behaviour would be instantiated in this respect.

To enable Autonomic Cooperative Behaviour one would need to employ the appropriate entities of the Autonomic Cooperative Networking Architectural Model, such as the Autonomic Cooperative Networking Protocol, particularly applicable in dense environments, where the neighbour discovery and link verification capabilities of the Optimised Link State Routing protocol would become highly useful. Thus, not only could the links between chief first responders and their respective first responders be monitored, but the mobile emergency operations centre would also acquire sufficient data to identify when another chief first responder could potentially enter into cooperation to serve an first responders belonging to a different team. In general, better robustness could be offered thanks to the operations performed by all of the mobile emergency operations centre, chief first responders, and first responders, as outlined in Figure 6.15. Consequently, having the relevant global data describing the status of the emergency communications network, the mobile emergency operations centre would even have some leeway in terms of prearranging cooperation before link degradation occurs. In particular, should a transmission request from a chief first responder be rejected by a first responder due to a transmission problem, the mobile emergency operations centre would be entitled to issue cooperation requests sequentially to both chief first responders. If both reply in the affirmative, then a relevant cooperation indication would need to be issued by the mobile emergency operations centre before the chief first responders could enter the cooperation phase.

Essentially, the process leading from the evaluation of specific radio links towards the ultimate Autonomic Cooperative Behaviour could be perceived as being carried out in two complementary, though not completely disjoint, ways, as depicted in Figure 6.16. Similarly to what was originally discussed on the introduction of the classification governing the routing protocols for mobile ad hoc networks, such as the Optimised Link State Routing protocol, it would be possible to assume either a proactive or a reactive approach in this respect. The choice between the two would clearly be conditioned on the required level of resiliency, expected to differ at specific stages of operation. Scrutinising the process itself, the starting points are related both to the monitoring of radio links and updating their information. At this stage it is not only clear that the proactivity-driven action could trigger the reactive one and not the other way round, but it also transpires that both processes may be ongoing within the same or different Autonomic Cooperative Nodes. Assuming that the same protocol would be exploited by each Autonomic Cooperative Node, such as the Optimised Link State Routing protocol, the default proactivity could also take a much more reactive flavour, for example due to energy constraints resulting from battery drainage and leading to an intentional reduction in the level of activity. In this mood, the following steps would involve either the notification related to link quality degradation or the arrangement for directing data stream to the supporting chief first responder, so that eventually it would be possible to enable or instantiate the Autonomic Cooperative Behaviour, respectively.

Finally, analysing the integration aspects of the ECN with the Autonomic Cooperative Networking Architectural Model, as depicted in Figure 6.17, one may see that the pattern applicable in this respect would be not significantly different when compared to other networked configurations. In particular, one would need to accommodate both the perpendicularity or orthogonally interrelated, from the conceptual perspective, Open Systems Interconnection Reference Model and Generic Autonomic Network Architecture, which in the figure go side by side solely for graphical convenience reasons, as the major interfaces through which the Autonomic Cooperative Networking Architectural Model may orchestrate the behaviour of the ECN. Such an orchestration would, in the first step, be related to the elevation of the chief first responders to the functional role of Autonomic Cooperative Nodes in order to establish the link with the routines of the Autonomic Cooperative Networking Architectural Model. In particular, through the formation of ACSs, such Autonomic Cooperative Nodes would be able to express Autonomic Cooperative Behaviour. This way it would become possible to integrate them with the workings of the Autonomic Cooperative Networking Protocol as a kind of a wrapper for the OLSR-protocol-based extended routing information enhanced algorithm for cooperative transmission (EREACT). Consequently, DSTBC-driven cooperative transmission over the VMIMO radio channel could be instantiated between the related chief first responders.

6.3.3 Cooperative Enhancement Justification

In order to verify the potential gains that could result from the employment of the above-mentioned principles of governance, as imposed by the Autonomic Cooperative Networking Architectural Model, especially with respect to Autonomic Cooperative Behaviour, a performance investigation of the related cooperative transmission with several different snapshots of various configurations of chief first responders located at fixed positions was carried out.¹⁵ To this end the baseline relay deployment indoor scenario was utilised, as originally depicted in Figure 4.20, along with the system parameters outlined in Table 4.5. Such an approach could be assumed since CFR deployments analysed at certain time stamps are equivalent to those featuring fixed relay nodes. The experiment was carried out in order to investigate whether an autonomic networking system in the form of an emergency communications network, with the capability of network monitoring and policy application, could benefit from cooperative deployment of chief first responders. One should note that normally the mobile emergency operations centre would be located outside such a building, yet, since it seems there are no standards defining what the relative positions of the two could be, it was assumed that the BS should be kept in the middle of the scenario, as in Figure 4.20. For each of the following figures, panel (b) shows the performance of the CFR2–CFR3 cooperative transmission, while panels (c) and (d) show the relative throughput attainable with single-path relaying via CFR2 and CFR3, respectively (Wódczak, 2012b).

First of all, it is assumed that the autonomic orchestration logic, to be upgraded later in this chapter to the notion of the cooperation orchestration decision element, would employ CFR3 at the same position in both the deployments presented in Figures 6.18 and 6.19. At the same time, the position of CFR2 would change, so that in the former case CFR2 would be placed closer to the BS thanks to which some improvement should be observable in comparison with the reference case detailed in Figure 4.22. In general, even though the throughput attainable thanks to CFR–CFR cooperation could be higher in certain regions, one might also consider employing the chief first responders disjointly in order to separately cover different regions of the area of interest. Consequently, as depicted in Figure 6.18(c), the case of single-path relaying using CFR2 should offer higher throughput in the rooms, and especially those immediately adjacent to the BS, and the corridor, while, according to Figure 6.18(d), CFR3 could better handle the remaining area. What is more, as becomes visible in the deployment shown in Figure 6.19, an attempt to compensate for the throughput degradation observable in the distant corners does not really provide satisfactory results, as the distance to CFR2 is too great. Thus, despite the reasonably satisfactory performance of CFR3, as confirmed by the results in Figure 6.19(d), overall CFR–CFR cooperation would be negatively affected and thus impractical, as shown in Figure 6.19(c) (Wódczak, 2012b).

Keeping in mind that in the case of the two above-mentioned scenarios, as well as the distance between them, as consequently the number of obstacles on the paths between the BS and each chief first responder can be different, two further possible deployments are evaluated as outlined in Figures 6.20 and 6.21. This time it is assumed that the autonomic orchestration logic ensures that chief first responders become selected for which the number of walls between them and the BS would be identical, while the distances were similar. Unfortunately, as much as the throughput achievable in the direct neighbourhood of the BS appears to be reasonably satisfactory, to follow Figure 6.20, the remaining area would not be covered sufficiently. All in all, it transpires that the issue of proper throughput provisioning in the case of the analysed indoor scenario is not a trivial question. On the one hand this might appear to be a serious drawback, yet, on the other hand, when the major theme of this book is taken into account, such a disadvantage should be perceived much more as a challenge. In fact, given the above context, as well as keeping in mind that the performance evaluation might be treated as providing at least a partial justification that cooperative enhancements may, in some cases, prove advantageous, the next step will be to extend the analysis to the aforementioned cooperation orchestration decision element of the network level. In particular, additional analyses of a variety of different deployment scenarios will be carried out, including modified positioning and denser setups, so that certain additional design directions can be provided.

6.4.1 Autonomic Cooperative Networking Architectural Model

Given that so far both the notions of the Autonomic Cooperative Networking Protocol and its related Autonomic Cooperative Behaviour have been scrutinised in utmost detail, as well as each chapter has presented complementary considerations in the form of additional analyses related to the architectural integration aspects, the description of the concept of the Autonomic Cooperative Networking Architectural Model, being the ultimate enabler of the Autonomic Intelligence Evolved Cooperative Networking, could seem to have already been fully exhausted. Such a perception is natural in the light of the approach assumed throughout the book, where the decision to provide a bottom-up description resulted, to certain extent, in the necessity of outlining incrementally arranged and context-setting characteristics, as indicated in the opening chapter. One should note, however, that although being fairly ubiquitous across the entire book, the Autonomic Cooperative Networking Architectural Model is still attributed to the highest network level, making it highly abstract from the very outset, just like the complementary levels of abstraction. In other words, there are certain more or less explicitly voiced outstanding aspects to be addressed to make the overall picture complete. In particular, once a consolidated summary of the Autonomic Cooperative Networking Architectural Model has been presented, the focus will initially shift to the question of the not yet fully definite relation between the Autonomic Cooperative Networking Protocol and the Autonomic Cooperative Behaviour, so that it is possible to advance the discussion and reflect upon the slightly dualistic role and place of the Autonomic Cooperative Networking Architectural Model.

In order to summarise the major conclusions arising from the incremental advancement of the workings of the said Autonomic Cooperative Networking Architectural Model, as well as provide sufficient background for the complementary analyses, a purposely elevated depiction of a consolidated version of the Autonomic Cooperative Networking Architectural Model is presented in Figure 6.22. In particular, special emphasis is laid on the representation of the frequently voiced perpendicular or even orthogonal positioning of the two major components of the Autonomic Cooperative Networking Architectural Model in the form of the specific developments attributable to each of the Open Systems Interconnection Reference Model and the Generic Autonomic Network Architecture. While the notion of orthogonality may be a bit artificial in this respect, mostly because of the fact that there exist certain cross-systemic extensions, to be elaborated further below on the occasion of the comparison of the roles of the Autonomic Cooperative Networking Protocol and the Autonomic Cooperative Behaviour, it has been repeatedly stressed across the entire book to underline the fact that both the developments belong to different worlds. It is then clear that the ultimate role of the Autonomic Cooperative Networking Architectural Model is to function as a means for the fusion of selected aspects of the two, arranged in a highly synergetic approach. Such a perception may be clearer if the representation is viewed as if it had been drawn three-dimensionally. One should note, however, that only in going back to the two-dimensional perspective is it possible to identify the extent to which the two may realistically overlap.

Such an overlap, referred to as cross-systemic extensions, is where the two key ingredients of the Autonomic Cooperative Networking Architectural Model, the Autonomic Cooperative Networking Protocol and the Autonomic Cooperative Behaviour, coexist. What is of interest at this stage of the description is the outstanding analysis of their precedence, especially given that, as previously outlined in Figure 5.25, even though the Autonomic Cooperative Networking Protocol appears to contain or cap the Autonomic Cooperative Behaviour when perceived from the top of the network layer, it is the Autonomic Cooperative Behaviour¹⁶ that interfaces with the cooperation orchestration decision element (CODE) of the network level. This duality is apparently caused by the fact that the previous depiction is, once again, two-dimensional, making it difficult to maintain the perspective of perpendicularity or orthogonality. In other words, as underlined more conspicuously in Figure 6.23, by belonging slightly more to the dimension of the Open Systems Interconnection Reference Model or that of the Generic Autonomic Network Architecture, the two notions need to be perceived separately. Attempting to understand such a division one would need to explore the roots of both Autonomic Cooperative Networking Protocol and Autonomic Cooperative Behaviour. In fact, as the former builds on top of the Optimised Link State Routing protocol, the latter stems from the notion of autonomic behaviour. While such origins could justify the reason for varying precedence, one should note that there is an undeniable common point between the two in the form of the multi-point relay (MPR) station selection heuristics.

Moving slightly away from abstract discussion and attempting to understand the practical side of the issue in question, one may ask whether it would be either the Autonomic Cooperative Networking Protocol or the Autonomic Cooperative Behaviour to take precedence in reality. Such a question appears especially valid given the architectural dependencies, as initially outlined in Figure 2.19, where it seemed to be the former that orchestrates the latter, thereby creating a possible contradiction with what was later concluded in Figure 5.25. In particular, assuming the baseline case of a mobile ad hoc network comprising a single domain where all the network nodes display equivalent capabilities, one could assume that the depiction presented in Figure 2.19 would generally hold, especially should all the said network nodes be elevated to function as Autonomic Cooperative Nodes. This would be so since, in such a case, the Autonomic Cooperative Networking Protocol could be perceived as the entity orchestrating the Autonomic Cooperative Behaviour instantiated by such Autonomic Cooperative Nodes. At this point one could refer directly to the Open Systems Interconnection Reference Model in order to elicit what the notion of orchestration may mean in this respect. This is necessary because orchestration tends to be understood as being performed in a centralised manner, where a specifically elevated entity is responsible for the entire process. After some consideration, however, one may conclude that the same task could be accomplished in a distributed manner if the presence of such a centralised entity were not expected or even allowable by default.

What the above explanation is intended to suggest is that an entity of considerable scope, possibly playing an inherently pivotal role in the whole design, may be perceived in a not entirely exhaustive way, just as if it had lost its formally elevated status, while in reality its privileged role still prevails. Referring more directly to the investigated case, especially keeping in mind that the Autonomic Cooperative Networking Protocol stems from a modified version of the Optimised Link State Routing protocol, which encompasses all the upgrades introduced with EREACT, one realises that the role of an otherwise network layer protocol is to be implemented within network nodes and function as a kind of interface between or among the same, over which they may establish a networked setup, so that neighbour nodes could exercise the tasks of communication and data transfer. A more concrete incarnation of such an understanding is outlined in Figure 6.24, where the Autonomic Cooperative Networking Protocol may suddenly be perceived as if it were reduced in terms of its role, while, in fact, this is by no means so. Given the above context, it transpires that the question of the precedence between Autonomic Cooperative Networking Protocol and Autonomic Cooperative Behaviour narrows down to identifying whether it is a high-level design that is scrutinised or rather a more specific instantiation thereof. In the former case it is much more reasonable to present the Autonomic Cooperative Networking Protocol on top, while in the latter the Autonomic Cooperative Behaviour takes the formal, yet not entirely factual, precedence.

Last but not least, there appears the question of the actual place and scope of the Autonomic Cooperative Networking Architectural Model, especially when the major theme of Autonomic Intelligence Evolved Cooperative Networking is concerned. In fact, the answer might, once again, not be too immediate or straightforward, since the perception and context of discussion may play a significant role in this respect. As far as the dimension of the Autonomic Cooperative Networking Architectural Model is concerned, where it builds on top of the Generic Autonomic Network Architecture, commonly known as an autonomic overlay, the same perception of an elevated entity may become the best representation thereof, especially since, in such a case, it also builds on top of the Open Systems Interconnection Reference Model related developments. Yet, quite contradictory to the Generic Autonomic Network Architecture itself, which remains quite detached from the said Open Systems Interconnection Reference Model, the Autonomic Cooperative Networking Architectural Model incorporates certain modified workings of the same, for example the Autonomic Cooperative Networking Protocol and its constituents. Consequently, a more complex depiction appears to present itself where the Autonomic Cooperative Networking Architectural Model is viewed not only as being an overlay, especially in more generic considerations, but also as encompassing all the discussed aspects, calling for a more detailed insight into it to be exercised. All in all, it appears that the major potentially outstanding issues have been concluded, and the focus can shift to the cooperation orchestration decision element.

6.4.2 Cooperation Orchestration Decision Element

Approaching the topmost cooperation orchestration decision element it is necessary to note that, as already explained, being located at the network level it should be perceived as if it were more of a virtual inclination. What is more, fairly alike it was the case for the protocol level of the Generic Autonomic Network Architecture abstraction structure, the nomenclature might pose certain dose of ambiguity, potentially inducing a similar level of uncertainty, since the notion of the network level should not be confused with the network layer of the Open Systems Interconnection Reference Model. In the case of the Generic Autonomic Network Architecture, the network level is usually referred to as being of a more intangible nature since it is only formed by selected or elevated network nodes. Most importantly, however, while, the network layer of the Open Systems Interconnection Reference Model generally pertains to the relevant networking protocols, along with their inherent addressing and routing schemes, the network level in question seems, to the contrary, to be a volatile incarnation of a particular networked setup as a whole. What is more, keeping such a context in mind, the cooperation orchestration decision element additionally appears to be an excellent illustration of the most recent considerations related to the precedence of the Autonomic Cooperative Networking Protocol and Autonomic Cooperative Behaviour. Thus, the following description will commence with an account of the prioritised role of Autonomic Cooperative Behaviour, so that it is possible to follow with specifically chosen scenarios and the assumed algorithmic description, along with the evaluation results.

The question of priority between the Autonomic Cooperative Networking Protocol and Autonomic Cooperative Behaviour results, most of all, from the nature of the assumed set of evaluation scenarios, which not only stem from the earlier discussed relay-enhanced cell, but additionally follow the hierarchical requirements imposed by the recently scrutinised specifics of emergency communications networks. In essence, it is assumed that a carefully selected configuration of a mesh-like grid of Autonomic Cooperative Nodes, by all means entitled to express Autonomic Cooperative Behaviour, is elevated above the operation of the Autonomic Cooperative Networking Protocol for reasons in line with the specifics of the highly illustrative case of chief first responders. Such an approach is possible because of a conceptual experiment where the Autonomic Cooperative Nodes are assumed to be fed over wired connections, rather than the wireless ones as it has been prescribed thus far, so that there would be no penalty for having a BS located centrally indoors or mounted externally on a MEOC. This way, the parameters described in Table 4.5 still hold with the exception of the first hop links, which in this context may be considered lossless, making it possible to apply the concept of the equivalent distributed space-time block encoder in its most canonical form. In other words, while the ACNP-driven communication of a mobile ad hoc network type would be not precluded, the Autonomic Cooperative Nodes would be entitled to express the Autonomic Cooperative Behaviour only.

The precedence of Autonomic Cooperative Behaviour clearly results from the nature of the scenario in question, and it is further highlighted by the structure of Algorithm 6.1, where the major routine is to be executed should the bit error rate threshold criterion be met for both network nodes under inspection. In fact, as indicated previously, such network nodes would be elevated to act as Autonomic Cooperative Nodes, and by forming an ACS they would instantiate the Autonomic Cooperative Behaviour. In this context, the results pertaining to the layouts of Figures 6.30, 6.25, and 6.26 are presented in Figures 6.27, 6.28, and 6.29, respectively (Wódczak, 2014a).¹⁷ Most importantly, the inner configurations denoted by 1, 2, 3, and 4 are arranged in an increasing order such that the Autonomic Cooperative Nodes belonging to each of the groups they represent are located farther and farther from the centre of the relay-enhanced cell.¹⁸ In fact, none of the above inner configurations may cover the entire area, thereby making the instantiation of the related Autonomic Cooperative Behaviour virtually indispensable.¹⁹ This is shown by the cumulative distribution functions (CDFs) indicating that layout B, and particularly the inner configurations labelled 2 and 3, appear to perform best. Although for layout A, with a more circular nature, the similarly almost identical inner configurations labelled 3 and 4 are most the advantageous,²⁰ such an arrangement pretends to be less efficient in comparison with the previous one. Last, but not least, layout C is also less efficient from this perspective, even though this time the inner configuration labelled 3 operates most effectively.

6.4.3 Architectural Integration Aspects

The time has come for some closing remarks related to the reoccurring architectural integration aspects. Given the fact that the outstanding issues pertaining to the Autonomic Cooperative Networking Architectural Model have already been discussed, the last topic of relevance relates to the mutual dependencies and synergies between all the decision elements introduced in this book, keeping in mind their residence at distinct levels of abstraction. Such a need becomes more evident the higher one moves in these levels of abstraction, being most clearly visible in the case of the cooperation orchestration decision element. Given the fact that the reliance one upon one another so evident among the decision elements is clearly directed top-down, a bottom-up approach to the analysis appears to be of most relevance, thanks to which the dependencies may be most exhaustively addressed. To this end, based on the algorithmic descriptions of the decision elements introduced thus far, illustrative structural depictions thereof will be presented, starting from the cooperative transmission decision element (CTDE), through both the cooperative re-routing decision element (CRDE) and cooperation management decision element (CMDE), up to the cooperation orchestration decision element (CODE). The reason for such an approach is related to the existence of certain functional blocks within the decision elements responsible for interfacing between themselves to make the entire Autonomic Cooperative Networking Architectural Model fully operational. In other words, an incremental analysis is assumed, intended to result in a comprehensive depiction of the above-mentioned dependencies and synergies.

Looking at the structure of the bottommost cooperative transmission decision element depicted in Figure 6.31, one may notice that, given the previously defined roles of the decision elements residing at certain levels of abstraction, such a decision element clearly belonging to the protocol level is bound to interface on the lower side with external entities only, at least when the top-down direction is assumed, being, in fact, equivalent to the vertical one given the introduced perpendicularity or orthogonality of the Open Systems Interconnection Reference Model and the Generic Autonomic Network Architecture. What is important from the perspective of this incremental description, however, is related to the fact that based on such an external interfacing the cooperative transmission decision element becomes entitled to offer certain services to some other decision element or decision elements located either directly at the level of abstraction immediately above or indirectly at even higher levels of abstraction. In the case of the cooperative transmission decision element such a service is related to the provision of increased robustness through the instantiation of DSTBC using specifically chosen code matrices. As a result of this approach a given decision element entitled to use the service of the cooperative transmission decision element, in the direct or indirect manner, becomes separated from having any influence on the choice made at the protocol level with regard to the code matrix to be applied, other than being able to impose certain requirements to induce specific behaviour thereof should it be physically possible to have it accommodated without penalty.

This is, in fact, what happens on the side of the cooperative re-routing decision element, located at the function level of the Generic Autonomic Network Architecture, which is responsible for the instantiation of either the Autonomic Cooperative Behaviour or fast re-routing. Looking at Figure 6.32, one may discern that, once again, there is a certain decision-making process ongoing, according to which it becomes necessary to identify what will happen when the quality of specific radio links falls below the expected threshold. However, even if the outcome of such a decision process is positive, meaning that Autonomic Cooperative Behaviour should be instantiated, it may only happen assuming that the ACS is not empty. In other words, in the narrow version referred to above, assuming the nomenclature behind the EDSTBE, the cooperative transmission decision element allows solely for switching between the and mode, yet, in general, it could also indicate that the operation of DSTBC may not be possible at all, thereby indirectly making the cooperative re-routing decision element switch to the alternative operation mode offered by fast re-routing. While this is what could happen given the local scope of the analysis, one should also take into consideration that, when perceived from the perspective of higher levels of abstraction, there could equally well appear a decision to reschedule some other transmissions in order to make room for imposing the demanded Autonomic Cooperative Behaviour, should it be really required to take place. This is, however, where the cooperation management decision element comes into the global picture.

As it may transpire from Figure 6.33, the cooperation management decision element has a much better overview of the mobile ad hoc network in question, as it interacts directly with the routines of the Optimised Link State Routing protocol, or rather its upgraded version in the form of the extended routing information enhanced algorithm for cooperative transmission (EREACT), through the wrapping provided by the Autonomic Cooperative Networking Protocol. Consequently, thanks to the most instrumental part thereof, being the multi-point relay (MPR) station selection heuristics, it may become possible to manipulate the process of the assignment of the related MPRs to the most relevant ACSs, and thereby also shape the aforementioned Autonomic Cooperative Behaviour. In other words, should it be known that a given transmission between a source node and a destination node over a group of network nodes elevated to the status of Autonomic Cooperative Nodes is to be given priority over the other transmissions supposed to take place in parallel, the pertinent ACS could be tailored accordingly, possibly at the expense of making the other ACSs suboptimal, to meet the imposed QoS requirements. To this end, the said communication between or among the relevant decision elements needs to be present in the background, especially since the functional block representing the instantiation of Autonomic Cooperative Behaviour, as depicted in Figure 6.32, may not be limited to the function level only, since it already reappears at the node level and, as explained earlier, its presence may be conspicuous even at the network level.

In fact, the topmost network level is where the cooperation orchestration decision element resides, as outlined in Figure 6.34. It is accountable for the organisation of the cooperation processes understood in a network-wide sense. Most obviously, there could be a single decision element of this type employed when a single-domain mobile ad hoc network is considered. However, one should not exclude multi-domain configurations, where the functionality of the cooperation orchestration decision element would need to be proliferated in a distributed manner, so that a logically centralised yet physically distributed entity would be obtained. Looking into its logic, one may discern that to some extent it operates slightly aside from the mainstream decision elements belonging to the levels of abstraction below the network level. It is so because of the elevated or even somewhat detached nature of the cooperation orchestration decision element, which operates in such a part of the overall abstraction that instantiates a nonexistent network device, being rather a composition of purposely promoted Autonomic Cooperative Nodes. Consequently, it no longer adds to the composition of Autonomic Cooperative Behaviour in general, but rather orchestrates the same, yet in a different way than is done for mobile ad hoc network internal transmission, taken care of by the cooperation management decision element. In other words, it is most applicable when the complexity of such a mobile ad hoc network becomes substantial and a hierarchical structure needs to be imposed, where cross-domain Autonomic Cooperative Behaviour may be established as in the case of the emergency communications network.