Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
120 Military Communications and Information Technology... technologies, having different properties with regards to e.g., range, are needed. Together the two radio links form a heterogeneous network. Within the German part of the convoy the IABG HiMoNN radio was used, whereas the Kongsberg WM600 radio was used within the Norwegian part of the convoy. To interconnect the two parts one German radio was placed on a Norwegian vehicle and one Norwegian radio was placed on a German vehicle. In addition to the vehicle nodes, one mobile network node was physically colocated with the deployable HQ network. This node connected the mobile network to the rest of the CoNSIS network, and was connected to mobile nodes terrestrial radio links as indicated. The eight vehicles formed two convoys, one German and one Norwegian. In the scenario, these two convoys were separated from the start, but at a later point in time, they merged into one large convoy. In addition, the network topology changed during the experiments, something that affected delay and available bandwidth. One such alternative topology is shown in Fig. 2. Figure 2. CONSIS network, alternative network topology Germany and Norway each provided implementations of selected parts of the NNEC CES, using Web services technology as their foundation. The two implementations were technologically quite different, as the German implementation, Referenzumgebung Dienste (RuDi) [1], is based on an Enterprise Service Bus (ESB), while the Norwegian solution consisted of multiple stand-alone components implementing the set of core services. In the experiment, the core services were used to provide a infrastructure for functional services providing three types of information:
Chapter 2: Communications and Information Technology for Trusted... 121 • Vehicle positions: Each vehicle reported its position (through a GPS-based positioning service) to the lead vehicle of its convoy. The lead vehicle then aggregated the positions of all convoy vehicles into a convoy Common Operational Picture (COP), which in turn was delivered to the HQ, where the two convoy COPs were aggregated into a full COP. This full COP was then distributed back to the vehicles. • Operational messages: This is a service for sending messages to other users. The messages can be of the types Alert, Warning, Information, and Command. File attachments are also possible. • Chat: This service provides ordinary chat functionality, based on chat rooms. All information types are distributed using WS-Notification, which is the Web service standard for Publish/Subscribe that is specified by the NNEC CES. Furthermore, all information types were distributed among all the vehicles as well as the HQ, as illustrated in Fig. 3. Figure 3. Information types and flows III. Service Discovery Service Discovery is the process of finding the services that are available in the network. NNEC CES has recommended the use of the registry based solution Universal Description, Discovery and Integration (UDDI) for this core service. However, when operating in a wireless network environment where node mobility and shifting network conditions can cause network partitions and loss of network connections, it is vital to use a service discovery mechanism that does not rely on the availability of any given node. In other words, we need a fully distributed service discovery mechanism [3]. The only standardized Web service discovery protocol that currently fulfills this requirement by operating in a distributed mode is WS-Discovery [4], which was utilized during the SOA experiments. WS-Discovery is designed for use in one of two modes: managed and ad hoc. In managed mode all nodes communicate through a discovery proxy, an entity
- Page 69 and 70: Chapter 1: Concepts and Solutions f
- Page 71 and 72: Selected Aspects of Effective RCIED
- Page 73 and 74: Chapter 1: Concepts and Solutions f
- Page 75 and 76: Chapter 1: Concepts and Solutions f
- Page 77 and 78: Chapter 1: Concepts and Solutions f
- Page 79 and 80: Chapter 1: Concepts and Solutions f
- Page 81: Chapter 1: Concepts and Solutions f
- Page 84 and 85: 84 Military Communications and Info
- Page 86 and 87: 86 Military Communications and Info
- Page 88 and 89: 88 Military Communications and Info
- Page 90 and 91: 90 Military Communications and Info
- Page 92 and 93: 92 Military Communications and Info
- Page 94 and 95: 94 Military Communications and Info
- Page 96 and 97: 96 Military Communications and Info
- Page 98 and 99: 98 Military Communications and Info
- Page 100 and 101: 100 Military Communications and Inf
- Page 103: Chapter 2 Communications and Inform
- Page 106 and 107: 106 Military Communications and Inf
- Page 108 and 109: 108 Military Communications and Inf
- Page 110 and 111: 110 Military Communications and Inf
- Page 112 and 113: 112 Military Communications and Inf
- Page 114 and 115: 114 Military Communications and Inf
- Page 116 and 117: 116 Military Communications and Inf
- Page 118 and 119: 118 Military Communications and Inf
- Page 122 and 123: 122 Military Communications and Inf
- Page 124 and 125: 124 Military Communications and Inf
- Page 126 and 127: 126 Military Communications and Inf
- Page 128 and 129: 128 Military Communications and Inf
- Page 130 and 131: 130 Military Communications and Inf
- Page 132 and 133: 132 Military Communications and Inf
- Page 134 and 135: 134 Military Communications and Inf
- Page 136 and 137: 136 Military Communications and Inf
- Page 138 and 139: 138 Military Communications and Inf
- Page 140 and 141: 140 Military Communications and Inf
- Page 142 and 143: 142 Military Communications and Inf
- Page 144 and 145: 144 Military Communications and Inf
- Page 146 and 147: 146 Military Communications and Inf
- Page 149 and 150: Use of Cross Domain Guards for CoNS
- Page 151 and 152: Chapter 2: Communications and Infor
- Page 153 and 154: Chapter 2: Communications and Infor
- Page 155 and 156: Chapter 2: Communications and Infor
- Page 157 and 158: Chapter 2: Communications and Infor
- Page 159: Chapter 2: Communications and Infor
- Page 162 and 163: 162 Military Communications and Inf
- Page 164 and 165: 164 Military Communications and Inf
- Page 166 and 167: 166 Military Communications and Inf
- Page 168 and 169: 168 Military Communications and Inf
Chapter 2: <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong> for <strong>Trusted</strong>...<br />
121<br />
• Vehicle positions: Each vehicle reported its position (through a GPS-based<br />
positioning service) to the lead vehicle of its convoy. The lead vehicle then<br />
aggregated the positions of all convoy vehicles into a convoy Common<br />
Operational Picture (COP), which in turn was delivered to the HQ, where<br />
the two convoy COPs were aggregated into a full COP. This full COP<br />
was then distributed back to the vehicles.<br />
• Operational messages: This is a service for sending messages to other users.<br />
The messages can be of the types Alert, Warning, <strong>Information</strong>, <strong>and</strong> Comm<strong>and</strong>.<br />
File attachments are also possible.<br />
• Chat: This service provides ordinary chat functionality, based on chat rooms.<br />
All information types are distributed using WS-Notification, which is the Web<br />
service st<strong>and</strong>ard for Publish/Subscribe that is specified by the NNEC CES. Furthermore,<br />
all information types were distributed among all the vehicles as well<br />
as the HQ, as illustrated in Fig. 3.<br />
Figure 3. <strong>Information</strong> types <strong>and</strong> flows<br />
III. Service Discovery<br />
Service Discovery is the process of finding the services that are available<br />
in the network. NNEC CES has recommended the use of the registry based<br />
solution Universal Description, Discovery <strong>and</strong> Integration (UDDI) for this core<br />
service. However, when operating in a wireless network environment where node<br />
mobility <strong>and</strong> shifting network conditions can cause network partitions <strong>and</strong> loss<br />
of network connections, it is vital to use a service discovery mechanism that does not<br />
rely on the availability of any given node. In other words, we need a fully distributed<br />
service discovery mechanism [3]. The only st<strong>and</strong>ardized Web service discovery<br />
protocol that currently fulfills this requirement by operating in a distributed mode is<br />
WS-Discovery [4], which was utilized during the SOA experiments.<br />
WS-Discovery is designed for use in one of two modes: managed <strong>and</strong> ad hoc.<br />
In managed mode all nodes communicate through a discovery proxy, an entity