SERVICE-ORIENTED ARCHITECTURE FOR COALITION SATELLITE COMMUNICATIONS Ramon Segura NATO C3 Agency (NC3A) The Hague, The Netherlands

ABSTRACT Communications interoperability between NATO and National forces is paramount in NATO deployments. In the recent past, the development of coalition inter-networking agreements at strategic and deployed levels has been progressing at a steady pace. In the satcom domain, interoperability at the physical, media access and sometimes network layers, largely relies on adopting common modem waveforms, as recommended by NATOs STANdardisation AGreements (STANAGs). Having NATO and Nations following the same satcom STANAGs is the first step to enable coalition-wide interoperable satellite communications. Establishing a system-agnostic service management overlay on top, to facilitate cross-support services amongst NATO and National space and ground satcom assets, becomes the next logical step. Under this framework, a service-oriented architecture (SOA) shall allow users within NATO, as well as users in a coalition, to discover and invoke satcom transmission services, advertised and provided through NATO or National ground and space assets. This approach, which relies on the federation of satcom networks and services from NATO and Nations contributing to a deployment, is facilitated by the migration to NATOs Network Enabled Capability (NNEC), and in particular, to converged IP networking over heterogeneous satcom bearers. This paper describes a candidate architecture to implement cross-support satcom services, both over static anchors, and deployed satcom networks. INTRODUCTION The new Satcom Ground Segment Reference Architecture (SGRA, [1]) is the first service-oriented Reference Architecture (RA) for satellite communications in a NATO coalition environment. Together with NATOs Information Infrastructure (NII) Communications RA (NCRA, [2]) and
978-1-4244-2677-5/08/$25.00 2008 IEEE

the Wireless Non-Satcom RA (WiRA, [3]), the SGRA is conceived with intensive NATO, National and commercial cross-support in mind. In the specific satcom context, cross-support aims at expanding coverage and reach, in line with NATOs new Level of Ambition (LOA), as described in the Ministerial Guidance of 2006. The LOA established new planning targets for NATO countries, to be able to conduct a number of smaller-scale but concurrent operations, greater than NATO has planned for in the past, while retaining the Alliances ability to carry out operations at a larger scale. Capabilities and service delivery requirements, within and beyond NATOs area of responsibility, are expected to drive satellite communications initiatives in NATO for the coming years. Besides providing detailed capability, operational and systems views, the SGRA defines a taxonomy of satcom-related services, spanning across static and in-theatre domains. These services, both within NATO alone, or involving cross-support between NATO and Nations, range from Transmission Services (for access, anchor and in-theatre communications), to Management and Control Services, as well as Information Assurance Services. The latter are critical in this context, because coalition satcom services will inevitably cross NATO and National security boundaries. On the other hand, the need to extend the geographical reach calls for a more dynamic and versatile satcom ground segment; one that can enable cross-support, and a true coalition-wide exchange of satcom services. Beyond todays core anchoring capability, NATOs future satcom strategy aims at expanded, more flexible and potentially ubiquitous access to satcom resources, with augmented anchor capabilities. That shall ultimately enable the high mobility and ad-hoc connectivity of STANAG-compliant terminals, as well as roaming across anchor stations, space segments and terrestrial transport networks (NATO, nationally or commercially exploited), world wide.

1 of 8

OPERATIONAL CONTEXT In practical terms, a Command and Control (C2) entity in a static HQ shall be able to reach a NATO deployed or tactical satcom terminal in a remote theatre of operations, by selecting a suitable static ground station, waveform, and satellite transponder, from a service description Registry. Likewise, a NATO expeditionary unit deployed in a remote theatre shall be able to reach its parent HQ, by unfolding its fly-away, and drawing a suitable reachback service from that same service description Registry (after which the terminal shall automatically align itself, tune to the assigned frequency pair, and close the link to the static ground station). These are simple examples that illustrate the potential of a SOA, in a land deployed/tactical context. While SOA agents in the static domain will access the Registry Services over the terrestrial network, equivalent agents in the deployed domain shall resort to any communications bearer of opportunity, to discover and invoke services that are only defined and maintained in the static domain. Over that same bearer, the agent shall exchange configuration and status data, as required to activate and monitor services, respectively, on its master satcom terminal. NATO terminals today can use their Advanced Satcom Network Monitoring and Control system (ASNMC) modems, as Engineering Orderwires (EOW) to exchange messages between deployed agents and parent agents at the static end. Conversely, in a coalition context, where no common EOW waveform may exist, more generic communications bearers shall be used. Low profile, lowcost, and small form-factor transceivers are good candidates (e.g. compact modems embedded in the agents single-board computer platforms). These transceiver shall feature global and reliable coverage, with IP access rates in the range of 2.4 kbps to 32 kbps, or higher (e.g. Inmarsat BGAN). Alternatively, agents may format and forward SOA messages over low-latency, non-IP Short-Burst Data services (SBD, e.g. Iridium). Versatile interface adapters and message wrappers at each end shall streamline the SOA messaging protocols, making them agnostic to the capacity and latency of the bearer of choice (or opportunity). Providing the above capability, concurrently to multiple, independent theatres of operations, with limited manpower

and technical skills, can be achieved best by integrating services provided across NATO, National and commercial satcom boundaries, using the concept of Enterprise Service Bus (ESB). The ESB is defined as a set of infrastructure capabilities implemented by middleware technology that enable an SOA [4]. In a coalition context, the ESB shall be implemented as a distributed, agent-based, heterogeneous infrastructure. It shall have different instantiations, which can be independent, e.g. ESBs existing separately at NATO and National levels, or may be closely coupled, e.g. registries synchronised between a Nations static and deployed ESBs. Besides the notion of an ESB, the SGRA introduces other supporting concepts to enable the most cost-effective and bandwidth-efficient implementation of the services. Amongst others, (a) flexible pooling and aggregation of heterogeneous, distributed space segment capacity, (b) oversubscription of resources, (c) clustering of deployed satcom assets (for reachback capacity build-up), and its counterpart, i.e. (d) virtualisation, of large satcom assets in the static domain, as well as (e) the integration of legacy (non-IP) and new generation (full-IP) modem technologies, through IP convergence. The aim is to improve diversity, deployability and survivability, irrespective of which assets are invoked for delivering the service, their affiliation, management and control authorities, and security boundaries crossed. That requires the ESB to interface the following two assets, in NATO and National teleports, deployed terminals, and control centres: (1) Satcom Convergence Routers (SCR). An SCR aggregates separately encrypted security domains, while providing satcom access through one or more legacy and IP-based modems. SCRs are standard COTS routers in anchor stations and deployed terminals, implementing policy-based, performancebased, and standard dynamic routing frameworks, largely relying on DiffServ QoS. (2) Satcom management and control systems, NATO and National infrastructure to remotely monitor and control (M&C) the components that make a satcom terminal (e.g. NATOs ASNMC). That may entail the adoption of narrowband transceivers, L-band services and tailorable M&C gateways, as quoted above.

2 of 8

Both the SCR and the ASNMC appliances (or National equivalent) shall offer an open OSS/BSS1 Northbound interface specification to the ESB. Through that interface they can be programmed coherently to implement services end-to-end. Alternatively, SOA wrappers can translate between any proprietary interfaces, and the standardsbased ESB interfaces. In the last instance, the ultimate integration option would be at the process level, through a workflow management system, which may involve manual operations (e.g. processing of work orders, service requests, performance data, etc.). FEDERATING SATCOM NETWORKS NATOs Network Enabled Capability (NNEC) is aimed at building communications infrastructures based on converged, multinational, BLACK-core IP networks, operated in a decentralized manner. These networks are independently managed, with a loose coupling between their information domains and the transport infrastructure, and a strong focus on high availability of services, also in high-threat environments [5]. This is opposed to the concept of closely-tied, centrally managed systems-ofsystems of today, heavily relying on mapping services to systems, and on building up those systems where they do not exist, in response to mission requirements. Instead, Nations are expected to contribute to the satcom infrastructure federation, while largely retaining control and confidentiality of their own satcom resources, policies and configurations, on both their space and ground segments. Satcom control will remain essentially distributed, with very limited infrastructure shared amongst the parties, under a federated provisioning and network management approach. National and NATO satcom control systems will be interconnected at standardised Service Interoperability Points (SIOPs). Service level agreements (SLA) will be enforced at, and through, those SIOPs. A common service provision overlay can then be implemented on top. This overlay will use common service interfaces, which plug on to potentially disparate management frameworks, through message wrappers. Services will still be defined end-toend, and enforced through bundles of SLAs (one per
1

segment, or transit leg), at the various SIOPs. These SLAs can invoke one or more Communications Profiles (CP), in turn supported by STANAGs and commercial standards. Figure 1 shows example CPs, relevant to satcom in a generic land tactical scenario. These are: CP-2, for deployable satcom, CP-5, for mobile satcom, and CP-8, for deployable satellite broadcast. These CPs support different land-tactical Operational Profiles (e.g. OP-1: deployable HQ, and OP-2: mobile C2 nodes).

Figure 1 Generic land-tactical satcom scenario

REQUIREMENTS OVERVIEW The requirements driving the proposed SOA are primarily motivated by the intended reach and goals of NATOs Response Force (NRF). and of expeditionary forces in general. The NRF will have its own deployable Communications and Information Systems (CIS) assets, which shall deploy under a five-day Notice-to-Move (NTM). Part of those assets will be highly deployable satcom terminals, providing backhaul and in-theatre backbone links, as well as serving as anchors for smaller NRF nodes (dubbed Small CIS Kits, or SCK), and ultimately satcom-on-the-move terminals (SOTM). These terminals may not always be sufficient, nor may be the space segment apportioned to them which, in some regions could not be even be available, or adequate for the mission. Moreover, some terminals may fall under a shorter, 48-hours NTM, and arrive at theatre well before any formal satcom provision arrangement can be established, dedicated capacity can be committed, etc. In

Operations and Business Support Systems (OSS/BSS)

3 of 8

this context, leveraging capacity and assets that NRFcontributing Nations may have already in the area, as well as later offering NATO satcom services to National troops joining the NRF deployment, justify a common service management overlay. In an NRF scenario, Nations contributing to the NRF may field their own satcom terminals to support their own deployed CIS requirements in theatre. Through these terminals and their National space segment, these Nations may offer shared satcom capacity to collocated NRF CIS enclaves. Conversely, these terminals may resort to NATOs space segment, to forward NATO traffic to deployed or static enclaves. This traffic is multiplexed with their National CIS traffic, at IP level. Other Nations contributing with troops and non-satcom assets, may wish to piggyback their traffic on NATOs NRF ground and space segments. These Nations require suitable access points to use these services. These are examples illustrating the rising need for NATO/National crosssupport, increasing with the number, distance and sparseness of concurrent joint-operations theatres.

SOTM terminals, or Ultra-High Frequency (UHF) manpacks, after landing in theatre. These terminals may connect to a large static hub, to a deployed intheatre hub, or become part of a meshed hubless network, and join nets already existing in the area (2) the seamless roaming of these terminals across theatres, or within the same theatre. During the first hours/days preceding a deployment, these terminals may support reconnaissance tasks, and be highly mobile, ultimately changing frequency bands (between X- and Ku-band), switching users or roles, and hopping between adjacent theatres, while in transit (see Figure 2). (3) the dynamic, transparent access to these deployed terminals from the static CIS enclaves (or other deployed CIS enclaves) END-TO-END SATCOM SERVICES Former satcom architectures in NATO have concentrated in defining transport services between well-delimited physical interfaces, connecting static and deployed/tactical satcom enclaves. Use of Nationally-supported services have been often limited to furnishing National modems at NATO teleports, to nail-up links from National shipboard platforms, serving as NATO command ships. In this context, cross-support operations have been link-oriented rather than service-oriented. Processing service requests, planning, provisioning, activating and sustaining communications services, relies on manual intervention and human expertise. Services are closely mapped to the physical link connecting the deployed terminal and the anchor station, making dynamic changes difficult, and manpower intensive. This is particularly true when terminals rove with advancing troops, and capacity is dynamically re-apportioned across terminals and theatres. The SGRA introduces a paradigm shift, from providing and managing homogenous satcom-supported transport services, edge-to-edge (i.e. between terminals), to managing differentiated satcom-enabled services, end-toend (involving satellite and terrestrial transit legs). The former largely rely on link-based connectivity, whereas the latter are based on packet-switched connectivity, with satcom being just another IP hop in the larger NATO WAN.

Figure 2 SOA and Roaming across space and ground segments

In practical terms, and from a NATO (or National) enduser perspective, the ultimate achievements of a SOA in this context would be, amongst others: (1) an agile, unattended, ad-hoc provisioning, automated configuration and link commissioning of any deployable satcom terminal, down to small fly-aways,

4 of 8

This federation capability shall allow any satcom-capable Nations to leverage their satcom ground segment investments, in support of coalition operations. Some may pioneer the fielding of emerging satcom waveforms, and share their infrastructure before NATO acquires its own. By seamlessly and selectively plugging services of their choice (vice systems) into the NATO WAN, Nations can act both as providers (publishers) and consumers (subscribers) of satcom services. Nations can decide which of their services are exposed to external subscribers and when, and which can be outsourced over to NATO satcom assets operating in the area. Services can be dynamically added and removed from the Registry, in response to e.g. capacity shortages, overbooking or apportioning of new resources, changes in National policy, etc. A Service Catalogue in a satcom SOA, and the associated satcom SLAs, shall clearly delineate service boundaries, as well as their invoked Communications Profiles, Provider/Consumer relationships and sharing of responsibilities, across Service Access Points (SAP), as described hereafter. SERVICE COMPONENTS AND BUNDLES End-to-end services in NNEC are segmented into component services. Satcom transmission services are component services, bundled or concatenated with other services in the terrestrial or satcom domains, to deliver the service to users at the end points, static or deployed. Transmission, management and information assurance service components can be invoked concurrently to meet a given upper-layer, end-user service specification, e.g. provide a 2 Mbps, TRANSEC2 protected, combined with a 32 kbps, jamming-protected, data dissemination service for fused sensor data products, with real time monitoring of the effective broadcast information rate. Component services in a given end-to-end service chain can be provided by NATO, by Nations, or both. For example purposes, consider a Bandwidth on Demand (BoD) service provided to a deployed NATO user. This service may encompass the following services, involve
2

different Communications Profiles, but be seamlessly offered to the NATO end-user as one service package: (1) an in-theatre reachback service, connecting the users deployed terminal (e.g. a NATO drive-away dish) to a National deployed hub terminal, in theatre. This service is solely provided by the Nation, delivering BoD to the NATO user, over a National transponder. Links terminate at the National Defence Network (NDN), in turn linked to the NATO WAN. (2) an anchor/backhaul service, connecting that same National deployed hub terminal to a NATO satellite ground station (SGS), over a NATO transponder. The service delivers fixed backhaul capacity into the NATO WAN, in turn linked to that Nations NDN. (3) a static reachback service, connecting the users terminal to a static BoD hub, which is part of a NATO SGS. As part of the reachback service, this SGS may offer access to broadcast feeds. In the context above, that NATO drive-away terminal can indistinctly make use of the three services, managed by different entities, but offered through a single manmachine interface to the user (e.g. a SOA Presentation Service). On the one hand, the user may request BoD on a National satellite spot beam, to reach NATO CIS enclaves that only exist in theatre (using the in-theatre reachback service in (1)). In parallel, some IP flows can be forwarded to a CIS enclave in a NATO static HQ, over a fixed-rate trunk on NATOs space segment (using the anchor/backhaul service in (2), i.e. a double hop). Last, the same terminal can get BoD from a NATO SGS, connect to the static NATO WAN over one hop, and receive broadcast from it, using the static reachback service in (3). In all three cases above, the Service Access Point (SAP) is at the same interface: the LAN port of the Satcom Convergence Router (SCR) of the NATO drive-away terminal. That port connects to the IP encryption device, in turn feeding the Secure Access Router (SAR), where the actual user services plug in. Once the service has been selected and activated, the ESB must forward orderwire messages to configure the SCR, the terminal RF front-end, and the modem(s). Further SOA messages can be exchanged in-band, once the link is established.

TRANsmission SECurity (TRANSEC), usually protecting waveform

signalling data and user data, while also adding traffic flow confidentiality (TFC) to prevent traffic analysis.

5 of 8

SATCOM NETWORK TIERS The SGRA introduces a tiered view of the NATO ground segment, closely coupled with the network centric paradigm. Networks are deployed and managed over multiple hierarchical tiers (see Figure 3). Tiers help segmenting the network into different, closely coupled topologies, in which a given asset may be operating over more than one tier (multi-tiered terminals). Tiers may include assets with different affiliations (NATO and National). Satcom services and Communications Profiles can be defined, provisioned and managed separately on each tier. Cross-support services between Nations and NATO can then be formulated, advertised and provided on a per-tier basis, or across multiple tiers. In terms of formulating cross-support satcom transmission services, the following four SGRA tiers are relevant: (1) Tier-1: high-capacity backhaul links, between terminals deployed in theatre and anchor stations in the strategic domain. These links can ride on Singlechannel Per carrier (SCPC) FDMA full-duplex symmetric trunks. Alternately, they can rely on Multichannel Per Carrier (MCPC), asymmetric carriers (featuring TDM outbounds and FDMA inbounds). Tier-1 obeys a generic star, hub-and-spoke topology, and often relies on fixed-rate carriers (ultimately with adaptive coding and modulation, ACM). Tier-1 waveforms shall comply to MIL-STD-188-165B (STANAG 4486 ed.3). (2) Tier-2: in-theatre backbone links, amongst deployed terminals of different sizes, affiliations. One may divide this tier into in-theatre anchor links, terminating at large deployed terminals (acting as forward deployed hubs for SCPC), and in-theatre partial or fully-meshed networks (relying on MCPC). Tier-2 can obey any topology, from star to meshed, or hybrid, and relies on the same waveforms of Tier-1. (3) Tier-3: reachback links, featuring bandwidth-ondemand, over TDM/MF-TDMA or TDM/FDMA waveforms, which can be oversubscribed. One may divide this tier into in-theatre reachback links, terminating at deployed BoD hubs, and static reachback links, terminating at static, large BoD hubs. Broadcast services are part of this tier, even if

no return channel for interacting with the sources is involved. Fly-away, drive-away, SOTM terminals, as well as small secure communications kits based on personal communications systems (e.g. BGAN), are also considered part of Tier-3. Tier-3 normally obeys a star, hub and spoke topology, mesh-capable with the new waveforms (e.g. Joint IP Modem, or JIPM). (4) Tier-4: encompassing all tactical satcom links. This is the tier of UHF and SHF man-portable terminals (a.k.a. manpacks). In particular, UHF terminals, over UHF Demand Assigned Multiple Access channels (DAMA), provide netted, any-to-any narrowband connectivity on-demand, to highly mobile units (as per MIL-STD-188-183B, STANAG 4231 ed.4 and STANAG 4681). Tier-4 also includes semi-tactical fly-aways subtending autonomous meshed networks in-theatre. These networks provide any-to-any hubless connectivity and DAMA access, with BoD and spectrum spreading, over MF-TDMA bearers. The U.S. WIN-T Network Centric Waveform (NCW) is an example of such advanced Tier-4 waveform.
Tier-1 (static anchor) Tier-2 (deployed anchor) Tier-2 (in-theatre backbone) Tier-3 (BoD reachback) Tier-4 (hubless mesh)

= NATO assets = National assets

Figure 3 Satcom Network Tiers (Tier-1 to Tier-4)

NATO and National satcom terminals can be multi-tiered, i.e. they may concurrently offer and subscribe to services over different tiers, through multiple waveforms (and modems), sharing the same RF front-ends. Thus, a large NATO SGS can have one RF head dedicated to BoD reachback links (Tier-3), supported by a DVB-S2/RCS hub. The same RF head may serve a stack of highcapacity, jamming-protected (EPM) FDMA modems (Tier-1). Within the same SGS compound, one may find one or more UHF heads and a DAMA controller, which can DAMA-tize any UHF channels in view of that SGS.

6 of 8

Conversely, a deployable terminal may have: (a) one SCPC modem to anchor into a larger terminal in theatre (Tier-2), plus (b) one TDM/MF-TDMA modem for static reachback purposes, receiving BoD from the static DVBS2/RCS hub in the example above (Tier-3), plus (c) one MF-TDMA modem to join a hubless mesh (Tier-4), in which this terminal can take the role of Network Controller (NC) of other, smaller terminals (e.g. sub-meter fly-aways, in use by special operations forces). Power permitting, all these services can be supported over the same RF front-end, concurrently through the same amplifier, over different transponders, beams, etc. Whilst the previous paragraphs described the tiers in terms of satcom Transmission Services, related Information Assurance Services and Management Services remain of utmost importance in a cross-support scenario. The most relevant Information Assurance services are mutual authentication of terminals, teleports, key distribution and exchange services. That may involve the use of PKI and X.509 certificates. Other services involve TRANSEC, Electronic Protection Measures (EPM waveforms, for countering RF jammers), boundary and intrusion protection services. The latter are often provided through IP firewalls, or guards operating up to session or application levels. These firewalls, NATO and Nationally managed, connect back-to-back at the SAPs. In the SOA context in particular, Security Services shall take care of authenticating the service agents. They shall also protect the registries where e.g. detailed modem configurations are stored, preventing the disclosure of potentially sensitive network configuration and management information to non-coalition parties. CROSS-SUPPORT SERVICE TAXONOMY Building upon the SGRA tiered view, a taxonomy for cross-support services has been produced. NATO and Nations shall adopt a common language to describe the services and communications profiles they can offer and support at each tier, respectively. They shall then populate and publish their service catalogues accordingly. Services over Tier-1 may be formulated as Access Services (or Gateway Access Services), or Anchor Services (or Satellite Access Services). The former are requested by parties in the static domain, and use satellite ground

stations (SGS) as gateways into the deployed or tactical domains. The latter are requested by parties in the deployed domain, and use deployable terminals as gateways into the static domain. All Tier-1 services use dedicated capacity (jamming-protected or not). Tier-2 and Tier-4 encompass services that only exist in theatre, amongst deployed entities. They can use NATO or National deployed assets, and NATO or National satellite capacity (usually over high-powered spot beams). Whilst Tier-2 largely relies on fixed-capacity and pre-assigned links, Tier-4 relies on contended access, with options for dynamic bandwidth allocation, netted connectivity, and pre-emption (of National over NATO traffic, or viceversa). NATO and National terminals can offer services in Tier-2, either as In-theatre Anchor Services, or becoming part of a partial mesh of trunks (as In-theatre Backbone Services). In Tier-4 however, services are primarily related to providing Control Orderwire Services for DAMA, such that terminals can log into the network, and interact anyto-any with other terminals (this applies to SHF, UHF). Tier-3 services use dynamically-assigned capacity on oversubscribed bearers, in response to traffic demands. Like in Tier-1, Tier-3 services can be formulated as Access BoD Services in the forward direction (request to access a deployed enclave, using a static or deployed BoD hub as a gateway), or in the return direction, as Anchor BoD Services. Tier-3 also comprises Static Broadcast Transmission Services, In-theatre Broadcast Transmission Services, and Broadcast Injection Services (i.e. broadcast contribution feeds from small terminals, often attached to mobile or static sensors). SERVICE ORIENTED ARCHITECTURE (SOA) Implementing a SOA for cross-support satcom services involves the following actors: (1) Service Providers; can be any ground or space segment assets, NATO and Nationally owned. The actual Service Provider is the management entity in charge of the asset (can be NATO, a National MoD, or a Service Provider delivering the service to a National MoD). (2) Service Registries; containing the metadata definition of satcom services and Communications

7 of 8

[2] FORWARD REQUEST

[3] DELIVER CONFIG

Profiles, supported by a Service Definition Language (SDL)3. Such SDL shall be agreed between NATO and the Nations, and shall ultimately become a STANAG. Independent Service Registries shall exist in each domain (NATO, National, Commercial). (3) Service Consumers; these can be NATO and National forces requesting satcom services, both from the static and deployed domains. Service Consumers use the Service Registries to look-up, discover and subscribe (invoke) satcom transmission services. Services can be offered by NATO and National ground segment elements, in the static and deployed domains. Each of the domains has its own ESB, and there can be static and deployed instances of it. The static ESB is accessed by static CIS users, who may invoke Tier-1 or Tier-3 access services to reach the deployed domain. Deployed terminals may access the static ESB over-theair, and invoke Tier-1 or Tier-3 anchor services that terminate at an SGS. If a NATO ESB cannot match a given service request in its Registry, it may relay the request to a National ESB (see Figure 4). SOA Agents embedded in deployed terminals may act as proxies towards the static or deployed ESB, to offer satcom services to CIS users in theatre. These agents may either take a proactive or reactive role, in terms of querying the static Registry. In the former case (proactive), an agent would query the static Registry for all the services offered through a given SGS. It would then pre-subscribe to those services of interest (e.g. backhaul fixed-rate anchor, BoD reachback, broadcast contribution), and update the deployed ESB accordingly. When local users query the latter, its Registry is already aware of which services are readily available through which terminal, and may provide an immediate response, and ultimately instantiate the service on the spot. Conversely, deployed terminals may act as reactive proxy agents. In this case, the agent will only act upon receiving a query from the deployed ESB, following a local user request (e.g. need anchor service). The agent will relay the query to the static registry, and subscribe to the service on behalf of the user.
3

NATO Static ESB

WAN Registry Adapters Security

WAN

out-of-band ESB orderwire (e.g. Iridium)

[4] F

Discovery

[1] R EQU EST OR W ARD C ON FIG

Orderwire

Adapter

Agent

SCR

NATO SGS

ASNMC Modems +RF

Nation-X Static ESB

Registry

LIS AB ST K ] E LI N [5

NATO Fly-away
(e.g. NRF SCK)

Adapters Security Discovery

Adapters

National In-theatre Hub

Nation-X Deployed ESB
Registry Security

National SGS

Discovery

Figure 4 Service invocation and relay (NATO to Nation).

SUMMARY The case for a SOA to deliver cross-support satcom transmission services in NATO has been presented. Operational requirements and a taxonomy of coalition satcom services have been identified and mapped to NATOs Satcom architecture (Tier-1 to Tier-4). The notion of static and deployed ESBs, with SOA agents embedded into deployed terminals, has been introduced. The key elements that interface to these ESB have been identified. Amongst those, out-of-band orderwire channels, supported by narrowband, global coverage, highly compact L-band transceivers, have been proposed for these agents to exchange SOA messages with their static and deployed ESBs. REFERENCES [1] Satcom Ground Segment Reference Architecture (SGRA), RD-2534, Ramon Segura, NC3A, February 2008 [2] NII Communications Reference Architecture (NCRA), RD-2511, Rob van Engelshoven et al., NC3A, March 2008 [3] Wireless Non-Satcom Reference Architecture (WiRA), RD-2548, Donald Kallgren, NC3A, April 2008 [4] Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 1, Rick Robinson, IBM, June 2004 [5] Protected Core Networking: An Architectural Approach to Secure and Flexible Communications, Geir Hallingstad, Sander Oudkerk, NC3A, IEEE Communications Magazine, November 2008

The

Tele-management

Forum (TMF)

NGOSS

management

architecture and associated SID (Shared Information and Data Model) is the standard framework for describing satcom transmission services.

8 of 8