spectrum architecture

UNCLASSIFIED

Model Futures Limited is a company registered in England and Wales with company number 05248454

Registered Company Address: 1 Nelson Street, Southend‐On‐Sea, Essex, SS1 1EG

VAT Number: 848 7357 75 MOD FATS/II: FATS/2/MFL DGFM Supplier Code: 46945

model futureswww.modelfutures.com

Spectrum Architecture Ian Bailey [email protected]

Version 1.1 27 April 2009

Prepared for:

Produced by Model Futures Ltd. under FATS/II

Model Futures Limited is a company registered in England and Wales with company number 05248454 Registered Company Address: 1 Nelson Street, Southend‐On‐Sea, Essex, SS1 1EG

VAT Number: 848 7357 75 MOD FATS/II: FATS/2/MFL DGFM Supplier Code: 56945

UNCLASSIFIED

UNCLASSIFIED 2


Introduction This report outlines an architectural approach to managing military RF spectrum in theatre. It suggests three approaches which are similar and mutually compatible, but which are aimed at different communities with different security requirements. The starting point for this work was the Bandwidth & Frequency view in the NATO Architecture Framework (NAF revision 3). Although this view can present the usage of spectrum by different systems, it does not take into account geographic considerations, which is a primary concern for coalition operations.

Problem Overview When coalition partners operate in the same theatre, there is potential for interference between the radio frequency systems used by each of the nations. Most nations have procured their own communications and ISTAR assets – either as sovereign assets or as modifications of imported systems. Although there is some degree of coordination in the way the nations procure systems, it is hard to avoid buying systems that use the same areas of the RF spectrum – especially as certain technologies such as RADAR and voice comms work most efficiently at specific frequencies.

Standards, such as SMADEF1, allow nations to share information about how their assets use the RF spectrum. SMADEF in particular is a very detailed data specification that allows enormous amounts of attributes and background information to be shared. What it lacks though is a standardised way to present this information so that operational decisions can be made more quickly and with more confidence.

Approach Enterprise Architecture is a technique for supporting business decision making by summarising salient facts from underlying data that may be very technically complex. For example, an enterprise architecture may record vast amounts of information about what systems can communicate with each other, where they reside, and what business activities those systems support. When this information is recorded with the appropriate detail and context, it allows architects to answer hitherto difficult questions such as “what activities can’t we support if we lose systems A & B ?” and “if we decide we no longer want to run activity X, which systems and sites can we shut down ?”. Enterprise architects tend to work with views2. These are standardised diagrams intended to convey the relevant information to certain stakeholders. For example, there may be views for IT and communications specialists, for process / doctrine modellers, or for programme managers.

The proposal here is to use a similar technique to EA for spectrum information – i.e. a standard way to present spectrum information to communications managers and commanders. According to Cave et al [1], the key factors in spectrum usage are:

• Frequency – the band or bands of frequency used by a given communications asset

• Power – the power of the transmitter of a given asset governs its range and therefore how close it can be to other assets using the same frequency without interference.

• Location – a number of factors rolled into one; where the asset is, the terrain surrounding it, and the direction(s) the asset transmits in.

• Time – when the asset is used and for how long it is used will determine if other assets can be used on the same frequency during the down‐times.

1 Spectrum Management Allied Data Exchange Format 2 For examples of these standard views, see the MOD Architecture Framework (MODAF) – www.modaf.org.uk

UNCLASSIFIED

UNCLASSIFIED 3


There are other factors influencing how RF systems might interfere, including the parameters of the receiving system (e.g. the level of filtering on the receiver). The purpose of the spectrum views will be to provide a quick indication of where interference is possible – i.e. they will be used as a guide for comms planning. Because of this, considerations about the receiving systems can be effectively ignored, as what we’re looking for is an indication of when two systems are operating in the same area at the same band3.

The purpose of this report is to examine how these factors can be summarised into simple diagrams along the lines of enterprise architecture views. Frequency is the easiest factor to present graphically, and the NATO spectrum views in NAF Rev 3 deal only with this. Incorporating the power and location factors brings in a number of complications around how RF propagation is modelled. There are a number of spectrum management tools designed specifically to do this and any architectural view incorporating location and power should seek to leverage these tools. Of the four factors, time lends its self least readily to graphical representation, though there are some approaches which may enable this.

The view specifications must take into account security considerations. Information about how spectrum is used for military purposes usually needs to be protected to some level. When information includes the location of the assets, the level of security classification can reach the very highest levels. This report considers three typical security scenarios:

• Open coalition including nations which have no previous working relationships. This may potentially also involve non‐governmental organisations which use RF equipment – e.g. aid agencies, construction firms, private security firms, etc. The sharing medium is likely to be internet.

• NATO nations in coalition operations, where secure networks such as the NATO WAN are available for sharing information.

• The AUSCANNZUKUS “five eyes” community in coalition, with GRIFFIN as the infrastructure.

The final consideration is the infrastructure itself, which in some cases may only be able to support simple web pages and graphics. The views, and their production methods, must take this into account.

3 See the “Level 3” approach on page 7 for an indication about how the characteristics of the receiving system can be handled.

UNCLASSIFIED

UNCLASSIFIED 4


Background

The NATO Architecture Framework Bandwidth & Frequency View This is a rather simple view, originally developed for NATO by Model Futures Ltd under sub‐contract to Serco. Its purpose is just to provide a spectrum‐oriented view of the systems in a given architecture. The information is presented by overlaying boxes on a radio‐frequency scale. The size of the box indicates the bandwidth used, and the upper and lower bounds of the box indicate the frequency range:

Figure 1 ‐ Example of a NAF rev 3 bandwidth and frequency view

The architectural models that NATO produces tend to represent systems of systems, and so emphasise which systems are required to communicate with which. For this reason, communication links may be overlaid on the diagram with additional bars to show the bandwidth used. Where a given system operates over more than one frequency range, it is represented as more than one box, connected by a vertical bar.

The purpose of this view is to present architectural information from a spectrum point of view rather than a coalition view of spectrum usage in a given theatre. Hence there is no information about the location of the systems, their signal strength or which nation owns them.

The NAF bandwidth and frequency view is deliberately simple – its aim is to simply provide a small amount of bandwidth and frequency information in support of NATO architectures.

SMADEF SMADEF provides a mechanism for sharing spectrum management information. Its scope goes well beyond frequency, power, location and time to cover tactical information, system manufacturers, angles of propagation, link budgets, etc. It is therefore capable of capturing all the information needed to produce useful spectrum views.

SMADEF specifies an XML interchange format for moving spectrum information between software systems. It has been implemented, at least to some degree, by a number of vendors of spectrum management systems. Given that such a large investment has gone into developing SMADEF, it makes a lot of sense to re‐use the specification as much as possible in any Spectrum Architecture work. In particular, the format is sufficiently detailed that some of the architectural views could be auto‐generated from underlying SMADEF data.

Freq

uency

UNCLASSIFIED

UNCLASSIFIED 5


Candidate Views Three types of views are suggested. Each is similar, but they are all aimed at communities with different levels of trust and security policies (and the appropriately protected networks).

Level 1 – Minimal Sharing This view is a slight enhancement of the NATO Bandwidth and Frequency view. In its simplest form, it shows how each nation uses the RF spectrum:

Figure 2 ‐ Level One Example (simple)

A view such as this is intended to be unclassified – there is no indication of what type of equipment is using each block of the spectrum, and no indication of where the equipment is located. Were nations prepared to share a little more information, the diagram could be enhanced with information about the type of equipment in use:

Figure 3 ‐ Level One Example (enhanced)

Even with this enhanced example, the hope is that it would be unclassified (nations can always choose to default to “Unspecified” if in doubt).

Level One is useful, in that a comms planner can quickly see how the spectrum is being used, and plan accordingly. In most modern warfighting and peacekeeping operations though, RF spectrum is heavily used, and different manufacturers of the same types of communication equipment tend to use similar frequencies, so the options for de‐confliction are limited. This is because there is insufficient information in the view to allow de‐confliction by location (i.e. geographically separating systems that operate on the same frequency). It may be possible to add a very high‐level geospatial aspect to Level 1 without giving away specific locations of systems (and so increasing the need for security):

Operation XXXXNation A Nation B Nation C Nation D

Civil Use in Theatre

Freq

uency

Operation XXXXNation A Nation B Nation C Nation D

Civil Use in Theatre

Freq

uency Voice

Data

RADAR

SATCOMMS

Unspecified

UNCLASSIFIED

UNCLASSIFIED 6


Figure 4 ‐ Level One Example (linked to a geographic region)

In the example above, the actual locations of the transmitters are not shown to any greater detail than the geographic region they are in. This would allow some degree of spectrum de‐confliction by operational area – e.g. any commander responsible for an operational area would know about the potential frequency clashes along the borders with other operational areas.

Level 1 is akin to the level of detail found in a national Frequency Allocation Table (FAT). Indeed, Level 1 could provide a standardised way to represent the data from an FAT. When a Level One approach is applied to a particular geo‐political area, the data from the appropriate FAT should be overlaid on the Level 1 view so that the domestic civil and military spectrum usage is also accounted for. The importance of the civil frequency data should not be underestimated – peacekeeping operations can often be conducted in heavily populated areas which may make use of a great deal of the RF spectrum. In some cases, there will be a need to ensure the military RF usage does not conflict with emergency services. In others, it may simply not be good from a morale point of view to interfere with the civilian mobile phone, data and television networks.

Level 2 – Geospatial Spectrum Management Level 2 adds geospatial information to the Level 1 view at a finer‐grain level by presenting the spectrum usage as a graphical overlay to a map. This sort of view should be familiar to anyone who has used modern spectrum management tools such as those offered by ATDI and similar companies. In its simplest form, Level 2 is a set of views, each view covering a different part of the RF spectrum, but covering the same geographic region:

Figure 5 ‐ Three Level Two views for the same geographic area

380‐850MHz 900‐1900MHz150‐350MHz

potential areas of interference

UNCLASSIFIED

UNCLASSIFIED 7


Level 2 views can also be presented with all the frequencies on the same map:

Figure 6 ‐ A single Level Two view with three overlaid frequency ranges

The clear difference between Level 2 and Level 1 is that is possible to infer the approximate locations of the systems that transmit on the different frequencies. Knowing that certain types of equipment tend to use certain frequency ranges, and that certain types of equipment are favoured for different military application, it is possible to further infer what is going on in the various areas of the map. None of this is beyond the wit of even the poorest funded intelligence agency to infer, so it is clearly information that needs to be protected. The level of required protection could be kept to a minimum by simply not showing those more sensitive users of the spectrum (e.g. special forces, HUMINT operatives, electronic warfare assets, etc.). Clearly, a balance has to be struck between how much is shared and how useful the view is (if very little spectrum data is shared, the view offers little potential for spectrum de‐confliction). Post cold‐war, there is an emerging consensus that there is more to be gained from sharing information than from simply protecting everything. Level 2 is clearly a case in point.

Level 3 – Attributed Spectrum Usage Level 3 is an extension of Level 2, providing the user with more detailed information about the assets in the view. The additional information would be of the sort found in the SMADEF specification – e.g. antenna direction, polarisation, military application, etc. The basis is still geospatial (as with Level 2), but the view becomes more interactive as the user can click on or “hover over” a particular transmission site and get more information about what is going on:

Figure 7 ‐ Example Level 3 view

380‐850MHz

900‐1900MHz

150‐350MHz

Region A, 9001900 MHz GSM Base-Station

Tag: XXX44YYBC/A

Owned by: Acme Telco

Usage: Constant

Location: 34° 35' N 69° 12' E

As with Levinvolved. It of sharing s

The examppropagationmoving tranchallenge, apicture mig(e.g. roads f

The known likely in Lev

With the adpresented. liable to be filtering, poLevels 1 andthat include

vel 2, the pis assumed ecret inform

ples shown n (they are insmitters is as these viewght. This reafrequently tr

Figure 8 ‐ Dire

routes of vevel 3.

dditional soIn particularaffected. Fa

olarisation, dd 2 are only es receiver p

Figure 9 ‐

potential benthat this sor

mation (e.g. t

up to now ntended to also possiblws are relatilly only leavravelled, air c

ectional transm

ehicles can p

phistication r, we are inteactors influendirection of aable to givearameters w

Receiver inform

U

U

nefits of thirt of view is ohe AUSCANN

for Levels 2be simple ee. The repreively static –ves the optiocorridors, et

mitter and route

present some

available inerested if thncing this arantennae, et an indicatio

would be able

mation display

UNCLASSIFIE

UNCLASSIFIE8

s approach only likely toNZUKUS com

2 and 3 shoxamples). Reesentation o– i.e. they doon of mappic.).

e of mobile tran

ething of a s

Level 3, infe receiving sre chiefly arotc.), and howon if there is e eliminate s

yed on level 3 v

ED

ED

have to be o be shared bmmunity).

ow static traepresentatioof moving traon’t change ng out the k

nsmitter (terra

security issue

formation asystems in thound how sew sensitive ita likelihoodsome of the f

view (terrain m

Microw

Tag: XX

Owned b

Usage: C

Location

Receive

Min Rece

weighed agbetween nat

ansmitters aon of directioansmitters pin real‐time known route

in map © Goog

e, so this lev

bout receivihe area of poelective the st is (e.g. rec of interferefalse positive

ap © Google M

wave Fixed-Link

X44YZBC/A

by: Acme Telco

Constant

n: 34° 32' N 69° 11' E

d Band : xxx-yyyGHz

eived Power: -3dBm

mod

gainst the setions who ha

and roughlyonal (e.g. fixpresents somin the way aes that the a

gle Maps 2009)

vel of detail i

ng systems otential intesystem is (e.geived powerence. A Leveles:

Maps 2009)

del futuwww.mode

ecurity risksave a history

y circular RFxed link) andmething of aa situationalassets travel

)

is only really

can also berference areg. frequencyr threshold).l 3 approach

ureslfutures.com

s y

F d a l l

y

e e y . h

UNCLASSIFIED

UNCLASSIFIED 9


Possible Implementation Strategies Any approach to implementing the spectrum views documented here will have to take into account the implied security requirements for each level described in this document. It will also have to account for the limitations of coalition shared networks (e.g. content restrictions) and deployed networks (e.g. bandwidth restrictions). Were it not for security concerns, some sort of application server approach would be the intuitive approach:

Figure 10 ‐ Application server approach

Although application server technology is well understood (all e‐commerce sites work on this principle), the issue of publishing to different networks at different levels of security is probably insurmountable. The networks usually have some sort of air‐gap between them when they operate at significantly different levels of security. Secondly, gaining accreditation for a system that serves data to multiple networks at different levels of security would be something of a challenge – especially if accreditation is required from all nations involved.

For these reasons, the strategy suggested here is based on simple web publishing – HTML and hyperlinked bitmap graphics (e.g. JPEG, PNG, GIF). These formats are well understood and present no challenges in terms of firewalls and virus/trojan control. Using such a simple approach to publication means that the majority of the analytical processing will occur during the production of the views. This will also mean that the views are relatively static – only Level 3 provides interaction, and even this is at the level of what is possible in a web browser. The approach suggested here assumes each nation will control what data it wishes to share and at what level. Each nation produces their own HTML and images and submits them to the Level 1, 2 or 3 server. Access to the data on these servers is assumed to already be controlled physically (i.e. non‐NATO nations can’t access the NATO WAN):

Figure 11 ‐ Suggested implementation approach

High Security Domain

Spectrum Database

Nation A SMADEF

Fileimport

Nation B SMADEF

File

Web ServerUNCLASSIFIED

Web ServerNATO RESTRICTED

Web ServerAUSCANNZUKUS

Security Filter XRejected

High Security Domain(e.g. Griffin)

Medium Security Domain(e.g. NATO WAN)

Low Security Domain(e.g. Internet)

Web Server

Web Server

Web Server

Nation B

etc.

Nation A

SMADEF File

BatchProcess

SMADEF File

BatchProcess Level 2

User

no access

air gap

air gap

UNCLASSIFIED

UNCLASSIFIED 10


The batch processes are controlled by each nation and produce HTML and images at the three different levels (shown as green, orange and red lines in Figure 11). The batch processing is not trivial, however, and will involve using advanced spectrum management tools to generate the necessary images, links and HTML. For this reason, it may be more efficient to submit SMADEF files to a central authority that generates the published data for all nations:

Figure 12 – Use of centralised publishing authority

This centralised approach allows views to be created which cover all the nations’ spectrum usage, rather than separate views for each nation’s operational area. It also presents some opportunities for efficiency:

• No requirement to train staff in each nation on how to produce the views

• No requirement to develop the batch process software for each nation

• No requirement to purchase spectrum management software in each nation

• Views will all be consistent in their presentation

• Single point of contact for issues with published data

What this does mean though, is that the publishing authority must be trusted up to the highest level of security being published. For this reason, it may be pragmatic to have more than one publishing authority – e.g. one for each level.

Extending the Capability The views produced in the three approaches are fairly static, and tend to just present the facts in an easily digestible form to the users (this is the purpose of an architectural view). There may be some additional benefit in highlighting known interference problems. For example, if two assets are seen to be interfering at the time the views are produced, it should be possible to a) highlight this in the view; and b) notify the owners of those assets of the potential clash – preferably before the assets are deployed. In this way, the view publishing authority also becomes a more proactive service to the nations.

The second obvious direction to take this approach is to map it onto situational awareness systems. Many of the RF assets in the architecture will be mobile. Knowing their spectrum usage and location in real time may be of some assistance operationally. This could be particularly useful in civil disasters and emergencies where multiple services (police, ambulance, fire, etc.) condense on a particular location and potentially face a number of communications issues. The technical challenges with this are not small – situational awareness systems already deal with vast amounts of real time data from multiple sources. In addition, standards such as JC3IEDM may not map cleanly onto the concepts in SMADEF.

PublishingAuthority

High Security Domain(e.g. Griffin)

Medium Security Domain(e.g. NATO WAN)

Low Security Domain(e.g. Internet)

Web Server

Web Server

Web ServerNation A

L1 SMADEF File

Level 2User

no access

BatchProcess

Nation B

L1 SMADEF File

L2 SMADEF File

L2 SMADEF File

L3 SMADEF File

L3 SMADEF File

air gap

air gap

UNCLASSIFIED

UNCLASSIFIED 11


Conclusions & Recommendations The approach outlined in this document has already been presented to CCEB (Feb 2009, NZ) and was well received. As it stands though, the approach is little more than a set of ideas. Wherever possible the approach errs on the side of pragmatism. In addition, it does not rely on any unproven technology. The only technical unknown is the level to which the production of the views can be automated. It should be possible to leverage the abilities of spectrum management tools to read SMADEF files and generate RF propagation images, but the extent to which this can be automated has not been tested. It is therefore recommended that some experimentation is conducted before adopting this approach. The experimentation should be geared towards:

a) Automation of view production from SMADEF files b) Testing of web publication on networks – e.g. NATO WAN, Griffin. c) User acceptance testing of views (i.e. do the users find them useful ?)

To make best use of time and resources, it would be sensible to engage one or more vendors of spectrum management software in the next phase. Should the experimentation prove positive (and there is no reason to expect serious problems) then CBM‐J6 should recommend this approach to CCEB for wider adoption.

References

[1] Essentials of Modern Spectrum Management, Cave, Doyle & Webb

Cambridge University Press, ISBN 978‐0‐521‐87669‐8

spectrum architecture

Documents