Ship Science & Technology - Vol. 14 - n.° 27 - (75-92) July 2020 - Cartagena (Colombia)
DOI: https://doi.org/10.25043/19098642.207
Arturo Arenas Castro 1
Geovanny D. Sánchez Marín 2
Guefry L. Agredo Méndez 3
Camilo E. Segovia Forero 4
1 Facultad de Ingeniería Electrónica y Telecomunicaciones. Universidad del Cauca. Popayán, Colombia. Email: arturoarenas@unicauca.edu.co
2 Facultad de Ingeniería Electrónica y Telecomunicaciones. Universidad del Cauca. Popayán, Colombia. Email: geosanmarin@gmail.com
3 Facultad de Ingeniería Electrónica y Telecomunicaciones. Universidad del Cauca. Popayán, Colombia. Email: gagredo@unicauca.edu.co
4 Facultad de Ingenieria Naval. Escuela Naval Almirante Padilla. Cartagena, Colombia. Email: camilo.segovia@armada.mil.co
Date Received: June 7th 2020 - Fecha de recepción: Junio 7 de 2020
Date Accepted: July 5th 2020 - Fecha de aceptación: Julio 5 de 2020
Tactical Data Link (TDL) systems are a kind of Mobile Ad Hoc NETwork (MANET) used in diverse maritime operational environments such as natural disasters, surveillance, maritime search, and rescue. A TDL network is usually composed of nodes or units representing surface ships, submarines, and aircrafts able to participate in maritime operations. A routing protocol is required to establish communication between nodes, which guarantees the route from the source node to the destination node. A TDL has been developed in the Colombian Caribbean Sea (CTDL). However, no efficient routing protocol has been implemented. This works to perform a preliminary study to implement an appropriate routing protocol for the CTDL.
Local environment constraints, in addition to the chosen protocols' performance analysis, will provide preliminary alternatives for a routing protocol with acceptable efficiency. This article provides a background of ad-hoc networks routing protocols, a description of the Colombian Caribbean maritime operational environment, a comparative analysis of routing protocols, and a discussion of conclusions and future developments regarding CTDL.
Key words: Routing, MANET, Table Driven, tactical data link.
El sistema de enlaces tácticos de datos (Tactical Data Link, TDL) es una especie de red móvil Ad-hoc (Mobile Ad-Hoc Network, MANET) utilizada en diversos entornos operativos marítimos como desastres naturales, vigilancia, búsqueda y rescate en el mar, entre otros. Por lo general, una red TDL se compone de nodos o unidades que representan buques de superficie, submarinos y aeronaves capaces de participar en operaciones marítimas. Los protocolos de enrutamiento son necesarios para establecer la comunicación entre los nodos que garantiza el establecimiento de la ruta desde el nodo de origen al nodo de destino. Se ha desarrollado un TDL en el mar Caribe Colombiano (CTDL); sin embargo, no se ha implementado ningún protocolo de enrutamiento eficiente. Por lo tanto, el objetivo de este trabajo es realizar un estudio preliminar para implementar un protocolo de ruteo apropiado al CTDL.
Las restricciones de entorno local, además del análisis de rendimiento de los protocolos elegidos, proporcionarán candidatos preliminares para un protocolo de enrutamiento con una eficiencia aceptable. El artículo proporciona antecedentes de protocolos de enrutamiento en redes Ad-Hoc, una descripción del entorno operativo marítimo del caribe Colombiano, un análisis comparativo de los protocolos de enrutamiento y unas conclusiones y desarrollos futuros con respecto a CTDL.
Palabras claves: Protocolos de Enrutamiento, MANET, Enlace de datos tácticos.
A TDL is an ad-hoc [1] network with a specific task, characterized for having two or more units (nodes) equipped with wireless communications with network integration ability establishing a direct or indirect (through relay nodes) contact. TDL features are self-organized and adaptative. Even when data is underway, the path from the source to the destination node requires no administration system. Ad-hoc networks could have different forms, such as mobile, standalone, or network of any other system.
Fig. 1 describes the functional elements of a TDL, which include a source node/unit willing to establish communication with another node called destination, directly or through relay nodes. Note that nodes have a Human Machine Interface (HMI), a processor module, and a transmission module that allows for information broadcasting.
Most TDLs are developed either by the North Atlantic Treaty Organization (NATO) or by private commercial companies. These developments are not open source, generic, or for general use. The customizing network is not available to the enduser, and the original equipment manufacturer is not allowed to release the network or system security parameters.
For the Caribbean Sea scenario, the mentioned TDLs do not fit all information requirements such as weather conditions, units positions, sea state, or the performance of the participating teams, among others.
Although there has only been one TDL implementation in Colombia [2], no evidence of routing protocols has been found in its systems. Therefore, introducing routing protocols is necessary to contribute to the efficient development of the Colombian Tactical Data Link (CTDL).
In the early 1970s, the first ad-hoc networks, packet radio systems, were implemented [3]. They used routing protocols for mobile networks and faced restrictions such as:
Currently, routing protocols have successfully overcome those constraints and have reached maturity to fulfill end user's needs.
This article provides an overview to recommend the appropriate TDL routing protocols to work in a specific maritime environment. To achieve these objectives, this paper provides a background on ad-hoc networks, followed by a description of the maritime operational environment in the Colombian Caribbean Sea and a discussion regarding routing protocols, including a comparative analysis among them and, finally, states the conclusions and expectations for future developments of the CTDL.
Ad-hoc networks [4], [5] are wireless means to set up communications in different kinds of unexpected maritime environments, jungles, and deserts, where no established communications systems are available. Each node should detect other nodes or units present in the operational scenario to perform a handshake to guarantee an active link, communication, data, and network services, among them. Concerning these issues, ad-hoc networks do not solely need to detect other nodes, but they must also identify the types of neighboring node devices and their features. The intrinsic characteristics of the ad-hoc-network include its infrastructure-less configuration without a predetermined topology or centralized control. There is no fixed base radio station, router, wires, or fixed routes, whereby routed information will change as per network node mobility changes, which will be reflected in the link connectivity. Ad-hoc networks face many other constraints, such as different hardware brands (computers, mobile phones, communication equipment, etc.), and power consumption becomes critical due to the relay of information packets between nodes, which requires hardware to work permanently.
Some of the challenges and difficulties [1] that ad-hoc mobile networks face are:
For this study, the important constrain is item #5. As mentioned in the introduction, the CTDL lacks a routing protocol. Hence, the initial requirement is to know the operational environmental conditions where the CTDL will perform to determine the routing protocol. This will allow the designer to determine the CTDL features such as network size, node quantity, node mobility features, as well as environmental conditions such as oceanic status, wind, etc.
The CTDL project [6] describes the Colombian Caribbean Sea environmental characteristics addressing end-user needs. Its scope is to enhance the operational direction performance, sensor integration, and information exchange in case of natural disasters, maritime domain awareness, and contributing to decision-making processes.
Usually, maritime operations are carried out in groups of units (nodes for ad-hoc networks), which can be surface vessels, aircraft, or submarines, according to each specific situation. Transmission of tactical information among them is fundamental to have a real-time scenario that enables operations coordination. The system must be secure and end user friendly, regarding the appropriate bandwidth use, and all the required software and hardware tools to visualize standard operation picture and information exchange among participant units.
The CTDL scenario composition is four vessels, one submarine, and two aircraft (one helicopter and one airplane). The analysis is performed considering each unit as a node having specific behaviors such as speed and altitude sensors and variables a ffecting the network like the line of sight and distance between nodes.
Weather conditions can influence a TDL design and its routing protocol. Therefore, factors such as humidity, air salinity, high temperatures, rainy and dry seasons, and all typical tropical conditions must be considered.
Now, certain features need to be considered for routing protocols to be able to perform in the maritime environment CTDL.
Need detaches from the essential CTDL requirement:
These features determine the implementation design of the routing protocol. End-user-needs can show the network topology. Functions and management can rule the network's size and density. The system offers the electromagnetic spectrum and bandwidth usage. Finally, integration capability drives network node quantity.
A designed scenario is essential; the CTDL simulation model is composed of two surface vessel nodes, one submarine node, one helicopter node, and one airplane node, as described in Table 1. The design purpose is to establish a future simulated scenario capability. This model must have assumptions, i.e., all nodes must be in the line of sight range, and nodes should establish communications in the same frequency even if there are different hardware brands.
Table 1. CTDL Scenario Composition.
From Table 1, and the CTDL features, it is possible to infer that:
Table 3. Comparacion of Proactive Protocols.
There are different routing protocol classifications, though Setup is the best known one. Kuosmanen [11] proposes other rankings based on various technical characteristics:
Regardless of how protocols are classified, the classification depends on their specific use, and they can be classified independently of the model. This article is based on the Setup model and breakdowns, as shown in Fig. 2 [1] of "Table-Driven" and "On-Demand systems.
Fig. 2. Routing Protocols.
Setup models are described as follows:
Coya Rey [12] explains MANET as the use of packets to discover nodes in a network and the path to reach them from or to a specific node. A given supposition is that all routes are already defined and, at some point in time, used. So, a table works to maintain updated route information; the main merit is that route information is permanently available, providing an easy way to establish the path from/to nodes. One of the drawbacks in MANETS is the existence of high amounts of data at each node, causing the network to slow down and the update process to be sluggish, especially when links are broken.
Venkat [13] states that route protocols are implemented in small networks with a high traffic density because of the constant packet information flow. Below is a description of the principal route protocols.
Every network node keeps a table with routing information, including all possible destinations, as well as its possible relay nodes. Therefore, route information will always be available regardless of the existence of the source node requirement of that information. Each entry is tagged with a sequential number assigned by the target node. This allows the relay nodes to distinguish between a worn path and a new one, thus avoiding routing loops. Tables are updated permanently and sent to the network to maintain consistency, causing high network traffic, which negatively impacts network resources usage. Full dump table update packets are used to improve this issue. This sort of packages carries all routing information and requires multiple Network Protocol Data Units (NPDUs, Relay Nodes). During the network's low tra ffic periods, packets are occasionally transmitted. Incremental small packets are used only for information that needs to be used by a relay node that has changed since the last full dump into the network.
WRP, Wireless Routing Protocol. Murthy [15] [16] describes this protocol, which addresses the issue of reaching free or direct links. It is a "Table Driven" protocol that keeps complete information in all network nodes. This model is a typical Route Discovery Algorithm, which in this case, avoids the issue of counting to infinite [17], forcing each node to perform a consistency check with all its neighbors on predecessor node information. This process eliminates loops and provides a quick convergence for route searching when links are broken. Each node must keep four tables:
LMR records the refresh message updates that need to be retransmitted and the neighbor nodes that need to confirm relay, and so on. The algorithm decongests the network's traffic channeling information flow to the appropriate route instead of across the entire system.
Each node sends an update after it has processed the receiving information from its neighbors or when changes are detected in neighbor links. In the case of a broken link between two nodes, each one sends a message to their respective neighbors. Neighbor nodes modify the distance table, and the possibility of new routes through other nodes is verified. The new route is relayed to the source node with information to update tables to reestablish the link.
Each node notices the existence of a neighbor when it receives "acknowledgment" (AKG), among other messages. Inactive nodes must send a "hello" message to ensure connectivity. Otherwise, the resultant link failure will be misinterpreted as a false alarm. When a node receives "hello" from a new node, it joins the routing table, and the routing table sends an update message with the information from the four tables to the new node.
CGSR is based on the DSDV protocol, consequently with the same DSDV high traffic load. However, CGSR includes a modification with an approximation to a hierarchical routing from cluster head node to output gate node (output gate node is a cluster relay node, named by the author) in tra ffic from source to destination node. Output gate nodes are within the communication range between two or more cluster head nodes. The source node sends a packet to accomplish communication between the source and the destination node, and it is first routed to a cluster head node, which relays the packet to another cluster head node using the relay provided by the output gate node. The process continues until the packet reaches the destination node. When using CGSR, each node must have a cluster membership table where the network cluster head destination nodes store the information. These tables are periodically spread through the DSDV protocol; all nodes update the cluster membership table through the transmission from one of its neighbor nodes. In addition to the cluster membership table, each node must have a routing table to determine the next relay node to reach the destination node. When a packet is received, the node's cluster membership table and cluster routing table identify the closest cluster head node in route, then the routing table determines the next relay node to reach the specified closest cluster head node and transmits the packet to it.
Grady [4] defines this category as protocols that only create routes within the network when a source node demands it. Once a route is established, it is kept by a maintenance procedure until the destination becomes unreachable or the route is no longer needed. Coya Rey [12] mentions that On-Demand protocols fit best in small networks with low nodes and static tra ffic patterns in a highly mobile system.
Shobana [19] argues that such protocols compared to proactive ones have higher power consumption and a more significant message delay; flexibility in operations is accomplished by reducing route loads considering that no loops form in TDL networks.
Meanwhile, the source node could execute other functions, such as forwarding packets. When the request packet reaches any relay node, it is compared to its cache or that of its neighbors to find if the destination route requirement is known or not. In case it is known, the node sends a response packet to the destination node. If unknown, the node will continue sending the same path request packet as when establishing a discovered route; the source node sends information on the destination path. The protocol adds a cache entry for future use; each node keeps the time information since the last cache entry to the actual one to know whether it is recent or not. When a packet reaches a relay node, it checks whether the packet is destined to it or not, in case it is a response packet sent; if not, the packet is forwarded as it is.
Fig. 3. (a) Route Creation, (b) Route maintenance in TORA.
If a link breaks during the maintenance process while the route is active, a new route discovery process to the destination node initiates, as shown in Fig. 3 part (b). In case of failure of the last descent direction link node, the protocol generates a new height reference, which is propagated to its neighbors. The links must invert to reflect the changes and to adapt to a new height. This also occurs if a node does not find a downlink (i.e., no longer finds neighboring nodes). The time factor is critical in this protocol because the determination of the "Height" metric depends on the logical time or time when a link breaks. TORA assumes that all nodes have synchronized clocks (probably by a GPS clock).
The metric used by this protocol has five components (1) Logical break time, (2) unique node ID that defines the new height, (3) bit reflection indicator, (4) Propagation order parameter, and (5) unique respective node ID.
Height is collectively represented by the first three, and a new height is defined whenever a node loses its downlink due to failure. In the deleting phase, this protocol floods the network broadcasting a CLEAR packet (CLR) to clear the invalid routes.
Taneja [20] mentions that this protocol uses arbitrary Height parameters to determine the direction of the link between two nodes, thus obtaining multiple paths for the same destination, none of which is necessarily the shortest. Additionally, when a node discovers that a route is no longer valid, it adjusts its height to the maximum value between neighboring nodes and thus transmits an update packet "UPDATE." If no neighbor nodes with a finite height concerning the destination are present, then it will start the process of discovering a new path that was already described.
Taneja [20] states that some of the benefits of TORA are the control of multiple routes between source and destination nodes, as well as the short time required to reestablish communication when a failure occurs by switching to another path. One of its disadvantages is that it involves clock synchronization among all network nodes. In order for this to work, it presumes that status detection, neighborhood discovery, packet delivery, and address resolution capabilities are easily accessible.
According to Coya Rey [12], Hybrid protocols mix proactive and reactive protocols. This type of routing is performed by "cluster," i.e., intradomain and interdomain simultaneously. Proactive protocols serve for communication inside a cluster, and reactive protocols, for communication between clusters. Zone-based or cluster protocols are used in large networks with many nodes. Some examples of these protocols are the Zone-Based Routing Protocol (ZRP) and the Adaptive, Hybrid Adaptive Routing Protocol (SHARP), among others.
Zone-Based Routing Protocol (ZRP). According to Toh [1], ZRP uses the merits of reactive and proactive protocols. Routing zones are similar to a cluster, but each node acts as a zone head and, at the same time, as a member of other clusters or zones.
Zones can overlap; each node specifies a radius in terms of radius nodes; the selection of the zone size has a significant impact on the performance of the Ad Hoc network.
Coya Rey [12] mentions that in order to build a zone, each node that is one hop away and could be reached directly has to be identified. The "Neighbor Discovery Protocol" (NDP) is responsible for controlling and searching routes and indicating when a route fails. This protocol broadcasts a query packet with the message "HELLO" at a specific interval. When zone nodes identify it, route tables are modified and updated.
The radius of length x determines zone dimensions, x indicates the number of hops from the source node to the zone edge, and it is also tied to the node emission power and other parameters. The protocol performance depends on the length of the x-radius that determines the zone area: small radius for small zones in dense networks that have high mobility nodes, and larger radius for more extensive areas, dispersed systems, and low mobility nodes.
Toh, [1] in section 5.12 states that ZRP handles three sub-protocols, (a) table-driven, called IARP Intrazonal Routing Protocol, (b) Interzone Routing Protocol (IERP Interzone Routing Protocol), and (c) Border cast Resolution Protocol (BCRP). Implemented IARP uses the "Link State" or Routing Distance Vector, across the border in the routing zone disseminating information. IARP depends on the NDP protocol to detect the presence of neighboring nodes, therefore nodelink connectivity, if any. Its primary mission is to ensure that each node in the zone has a consistently updated routing table that reflects the information of how each node in the zone is able to reach other nodes. IARP relies on edge nodes to execute on-demand routing to find information about nodes outside their zone. IERP uses the BCRP protocol in replacement of the query message "HELLO" when propagating within another zone.
According to Haas [36], one consideration about ZRP is that it handles different protocols according to zones, and this affects the performance efficiency of interzonal communication, and the route search can be unstable and challenging. Without proper query control, ZRP can have reduced performance than typical protocols based on "flooding." Inside a zone, a route failure due to node mobility is treated with a proactive protocol; the node reports the loss to every zone node, which, upon information reception, update their route tables. If route failure is due to an edge node or a different zone node, route repair runs like a new route search. In the worst case scenario, the failure route message is sent to the source node.
The last lines describe the protocol operation and compare the algorithm's main characteristics. Now some differences will be exhibited. Time complexity is smaller in WPR than in DSDV because the latter informs only the neighboring nodes about the link status changes when a link fails. When additional links are established, the "HELLO" packet is used as a presence indicator to allow the entry to update the routing table a ffecting the neighboring nodes exclusively.
In the CGSR, the routing performance depends on the status of specific nodes (cluster heads, output nodes, or normal nodes). Link failure time complexity is associated with a cluster head and is higher than in the DSDV protocol due to the need for extra time to select a new cluster head. In the same way, this applies to the selection of new nodes links that are associated with cluster heads.
In terms of communications complexity, since the DSDV, CGRS, and WRP use shorter Path Distance Vector protocols, all of them have the same degree of complexity during link breakouts and additions.
Reactive Protocols comparison in Table 4 shows that the AODV protocol, like the DSR, use the same procedure to find a source to destination node path. However, it differs from the fact that DSR has a higher load in each used packet to carry established route information. In contrast, the AODV only carries the destination route information. This also happens with packet responses and in-memory loading of each protocol. AODV is the only compared protocol that can perform multi-broadcast.
The requirement of link symmetry between nodes is a drawback of the AODV protocol being unable to use asymmetric links routes, unlike DSR, which is able to use asymmetric links when symmetric ones are not available.
The DSR [23] protocol performs best on moderate mobility nodes networks concerning packet transmission latency, and this presumption provides a small network diameter, which allows all nodes to become receiving nodes. Hence, the network management software receives any packet without a filter or restriction provided by the destination address.
The DSR does not perform periodic broadcasting requirements saving bandwidth and power consumption. Therefore, this protocol is not overloaded when there are no network topology changes. Additionally, it allows each node to keep information of all routes established to the destination node in its cache. Thus, when a link is broken, relay nodes can check their cache for another path. If not found, the protocol invokes the algorithm to find a new route. In the DSR, the recovery of a route is faster than in other algorithms. However, due to the DSR small diameter, it is not scalable to vast networks.
The TORA is an "inverted link" type algorithm, according to Park [24]. This protocol is best suited to large networks with a dense node population. DSR and TORA are the only two protocols capable of establishing more than one route between the source and destination nodes. Rebuilding routes is not necessary until all possible paths have been considered valid. Therefore, bandwidth is retained. Another advantage of TORA is the multicast capability, which, unlike in AODV, is not incorporated in the essential operation but performed by means of a dedicated sub-algorithm called Lightweight Adaptive Multicast Algorithm (LAM). TORA and LAM enable the multicast capability. TORA depends heavily on node clock synchronicity. Network nodes must have a GPS or any other mean to control time to allow performance.
Table 2. Comparacion of Reactive Protocols.
Route recovery is not as expeditious in TORA as in other protocols due to potential oscillations within this period, which can cause long delays until a new route is determined.
Proactive protocols are based on routing tables that store information for all possible routes demanding this information to be broadcasted continuously or table updates being issued. These activities require higher power consumption, broader bandwidth, and produce considerable delays. These demands provide the advantage of more robust links that remain without breakouts for much longer.
Information management based on demand corresponds to reactive protocols, so their efforts are materialized only when necessary, either to establish a new route or to repair a broken link. Reactive protocols' advantages are low power consumption, less data traffic improving bandwidth exploitation. However, unlike proactive protocols, these routes are less robust, and rebuilding routes takes much longer, causing delays or link loss. Finally, this comparison will be analyzed later for benchmarks and the simulation process to meet the main objective of this work, which is to recommend as far as possible the best protocol to be implemented in the CTDL.
In reactive protocols, broadband usage is optimized because of less load on messages. On-demand traffic, no requirements for continuous updates, and low tra ffic assure the protocol's excellent performance. Thus, reactive protocols perform better than proactive ones in the update and link-breaking recovery processes since the proactive ones require constant table updating, and therefore information tra ffic becomes congested. Among reactive protocols, TORA and AODV have the multicast capability, while among proactive protocols, only the CGRS has this capability through a secondary algorithm. Bandwidth consumption is lower, especially in TORA and DSR, because the messages are only sent on demand, in contrast with them being sent continuously in proactive protocols.
All the routing protocols keep links between nodes as long as route information is maintained; however, Table-Driven protocols work better because the information is always available. Considering the aforementioned theoretical performance algorithms, it can be concluded that proactive protocols have a lower delay in messaging. Another advantage of proactive protocols is that they usually select the shortest path, which is the most powerful to create stronger links. Regarding node quantity, relatively few protocols have improved performance, particularly the DSDV protocol.
There are many features of routing protocols that are not actually usable by the network posed in this maritime scenario, as well as others that would not differ in their implementation, such as power usage because the participating nodes have a constant power supply. Both reactive and proactive protocols perform well in small networks of moderate traffic and low density, but as the system grows in density and traffic, advantages and disadvantages show up. In terms of latency, routing protocols would be well implemented on the network because actual usage dynamics allows delays for up to two minutes without being critical. The CTDL implemented features clock synchronization via GPS used to determine node position and media access control when required. This capability would be available if the TORA protocol is implemented. Regarding network size for simplicity purposes, flat and non-hierarchical protocols should be implemented.
This study allows us to infer that reactive protocols might work better than proactive protocols in CTDL, mainly because of bandwidth consumption. This issue is critical because of the hardware limitations mentioned in the CTDL for maritime scenarios. Hence, according to the analysis for this type of reactive protocol (On-Demand), the DSR might perform better.
Validation of this preliminary study employing a simulation tool that allows for adjustment of results with the obtained data is required as future work.
[1] C.-K. TOH, Ad Hoc Mobile Wireless Networks, Protocols and Systems, Upper Saddle River, New Jersey: Prentice-Hall, 2002.
[2] S. M. L. S. M. T. GUSTAVO PEREZ VALDEZ, "Desarrollo de un Enlace de Datos Tactico, Fsae 1: Prototipo," COTECMAR, Cartagena, 2012.
[3] I. BOLT BERANEK AND NEWMAN, "A History of the ARPANET," DARPA, Arlington, Virginia, 1981.
[4] J. P. O. GRADY AND A. MCDONALD,"State of the Art: Ad Hoc Networking,"M-Zones Deliverable 1, vol. State of Art Surveys, no. 2, pp. 16-26, Mayo 2003.
[5] C. L. G. JR., "Data Link Communications Tactical Air Command and Control Systems," IEEE JOURNAL SELECTED AREAS IN COMMUNICATIONS, vol. SAC 3, no. 5, pp. 779-790, 1985.
[6] J. M. GOMEZ T., W. A. CASTRO C, G. PEREZ V, S. MARRUGO LL. AND J. VILLEGAS D, "Codesarrollo de un Sistema De red Tactica Naval .....," COTECMAR, Cartagena, 2015.
[7] B. TANG, BAOLIU YE, L. SANGLU, G. SONG AND I. STOJMENOVIC, "Latency-optimized Broadcast in Mobile Ad Hoc Networks without Node Coordination," in MobiHoc 2014, Philadelphia, PA, USA, 2014.
[8] K. A. JAGADEV, K. B. PATTANAYAK, K. M. MISHRA AND M. NAYAK, "Power and Delay Aware On-Demand Routing For Ad Hoc Networks," IJCSE International Journal of Computational Science and Engineering, vol. 02, no. 04, pp. 917-923, 2010.
[9] M. GERLA, L.-J. CHEN, Y.-Z. LEE, B. ZHOU, J. CHEN, G. YANG, AND S. DAS, "Dealing with node mobility in Ad Hoc wireless. Network," UCLA, Computer Science Department, Los Angeles, California, 2005.
[10] NORTHROP GRUMMAN, LINK 22 Guidebook Overview, San Diego, California: Space & Mission Systems Corp., 2010, p. 120.
[11] P. KUOSMANEN, "Classification of Ad Hoc Routing Protocols," Helsinki.
[12] L. COYA REY, T. O. LEDESMA QUIÑONES AND W. BALUJA GARCIA, "Protocolos de enrutamiento aplicables a redes MANET," REVISTA TELEM@TICA, vol. 13, no. 3, pp. 59-74, 2014.
[13] M. VENKAT AND N. KASIVISWANATH, "Routing Protocols for Wireless Mesh Networks," International Journal of Scientific& Engineering Research, vol. 12, no. 8, 2011.
[14] C.-K. T. ELIZABETH M. ROYER, "A Review of Current Routing Protocols for Ad Hoc Mobile Wireless Networks," IEEE Personal Communications, vol. 6, no. 2, pp. 4655, April 1999.
[15] S. MURTHY AND J. GARCIA-LUNA-ACEVES, "A Routing Protocol for Packet Radio Networks," Proceedings of ACM First International Conference on Mobile Computing & Networking MOBICOM95 , Noviembre 95.
[16] S. MURTHY AND J. GARCIA-LUNA-ACEVES, "An efficient Routing Protocol for wireless Network," ACM Mobile Networks and App. J., no. Special on Routing In Mobile Communication Network, pp. 97-183, Octubre 1996.
[17] A. TANENBAUM, Computer Networks, vol. 3, Englewood, New Jersey: Prentice-Hall, 1996, pp. 357-358.
[18] C. -C. CHIANG, "Routing In Clustered Multihop, Mobile Wireless Networks with Fading Chanel," in IEEE SICON 97, Singapore, April 1997.
[19] M. SHOBANA AND S. KARTHIK, "A Performance Analysis and Comparison of various Routing Protocols in MANET," in Proceedings International Conference on Pattern Recognition, Informatics and Mobile Engineering, Tamilnadu, India, 2013.
[20] S. TANEJA AND A. KUSH, "A Survey of Routing Protocols in Mobile Ad Hoc Networks," International Journal of Innovation and Technology, vol. 1, no. 3, pp. 279-285, August 2010.
[21] M. SHOBANA AND S. KARTHIK, "A Performance Analysis and Comparison of various Routing Protocols in MANET," in International Conference on Pattern Recognition, Informatics and Mobile Engineering (PRIME), Tamilnadu, India, 2013.
[22] H. T. DUYEN, W. BENJAPOLAKUL AND P. D. MINH, "Performance evaluation and comparison of different ad hoc routing protocols," Computer Communications, pp. 2478-2496, 4 May 2007.
[23] D. JOHNSON AND D. MALTZ, "DYNAMIC SOURCE ROUNTING IN AD-HOC WIRELESS NETWORKS," in Mobile Computing, T. Imielinski, and H. Korth, Kluwer, 1996.
[24] V. PARK AND M. CORSON, "A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks," in INFOCOM 97, Kobe, Japan, 1997.
[25] S. MURTHY AND J. GARCIA -LUNA-ACEVES, "Loop-Free Internet Routing Protocol Using Hierarchical Routings tress," in INFOCOM '97, Kobe, Japan, 1997.
[26] C.-C. CHIANG, M. GERLA, AND L. ZHANG, "Adaptative Shared Tree Multicast in Mobile Wireless Networks," in GLOBECOM 98, Sidney, Australia, 1998.
[27] L. JI AND M. CORSON, "A lightweight Adaptive Multicast Algorithm," in GLOBECOM 98 , Sidney, Australia, NOV-1998.