by
Adrian Graham
BEng. CEng. MIEE. - ATDI Ltd.
www.atdi.co.uk

The care of every emergency services radio communications Officer is to ensure that the radio network meets the requirements of the department as a whole. Traditionally, this has been performed in-house, but increasingly, radio services are bought in from commercial sources, and it is the job of the comms Officer to ensure that this network meets the requirements without the benefit of leading the network development activity. This leads to a new problem; how can the network performance be assured when the people developing and managing the network are not those who will ultimately use it, and when they may also have different primary considerations, such as maximising profit obtained from the network?

This potential problem area is causing more than a few headaches in the emergency services community, and rightly so. Even the most dedicated contractor will still find it difficult to make sure the network they will design will meet the requirements of the user in the field, and even if it does, how will this be proved?

Many articles and discussions have centred on the subject of network verification. This is indeed and important issue, but it ignores the crucial aspect; network validation. Too often, this is glossed over in the rush to look at verification. First, we need to identify the differences:

Validation is the activity of ensuring that the network design meets the users requirements (are we building the right network?).
Verification is the activity of ensuring that the network meets the criteria laid down in the specification (are we building the network right?).

The crucial aspect is that the network cannot be verified against the user's needs because, in general, the user's needs are not expressed in an appropriate manner. As a basic example, ask a police officer what he requires of the radio network and he or she will probably say something along the lines of, "it must provide 100% communications ability from 100% of the places I expect to work". From the user's perspective, this is not unreasonable, but from an engineer's perspective it is clearly unworkable. Nothing works 100% of the time, and it is financially and technically impossible to implement a network with 100% coverage. Some other definition must be generated, and it must describe the requirements in sufficient detail to ensure that the network that meets the specified objectives (the specification) and that in turn, that specification meets the users' (reasonable) requirements, as interpreted by the comms Officer. This task is very far from being trivial and it is often given far too little thought; it is, in fact probably the single most important activity in the project, and one of the most technically and intellectually demanding.

Although there are too many factors to go into in this short article, it is worth illustrating the issues by two factors; coverage area and what we will call performance level.

Firstly, coverage area. Well, this is a simple thing to determine isn't it? We need coverage over the whole force operational area? Fine in principle, given an unlimited budget. In practice, it is almost certain that some kind of prioritisation will be required.

An example of this is the question; are major population centres to be treated in the same way as rural ones? The answer is almost certainly that urban areas will be more important than rural ones; the emergency services serve people after all. So let's say that the requirement is to serve areas with a population of over 1000. This can be expressed to the contractor, but in fact it is a worthless description. How is an area defined in this context? Is it a built up area, or the summation of a large tract of sparsely populated rural territory. One method of establishing this is by user density. The definition could therefore be refined to; those areas with a population of over 1000 and a user density of 100 people per square kilometre, for example.

This definition is more reasonable and it appears relatively defendable, however in contractual terms it is more full of holes than a Swiss cheese factory. Some areas of contention that might arise include the following:

How will the population/density figures be derived? Other than by counting each individual, it is impossible to know. Census information is always out of date and in any case - which census figures will be used?
What time of the day are we talking about? When people are working or when they are at home? Do you really want to plan the whole network based on where people sleep rather than where they spend most of their time?
Assuming that some kind of computer analysis will be used (as it must be in order to get the level of detail required), how will the geographic and social environment be modelled? Which datasets are acceptable? One data set may express population on a post code basis, with the total population assumed to be on the centre of the post code area. Is this acceptable, or must the population be distributed throughout the area? By what method? As for the environment data, how well defined will that be? To the nearest kilometre? Nearest 100 metres? Nearest metre?

Illustration Caption Image 1: The ability to specify coverage precisely means that the network can be designed to meet the users' requirements as efficiently as possible.

These are only an illustration of the contentious issues that can and, unless expressed to mutual understanding as early as possible in the process, will cause friction and may lead to the wrong network being presented. The aim is to resolve these issues without having to go to court, and this can only be done by very detailed and precise analysis.

This analysis should be broken down as far as possible to avoid confusion.

Illustration Caption Image 2: Different categories of environment and coverage requirements can be specified, and the precise amount of coverage achieved can be computed. This can be shown graphically and statistically.

It is also necessary to spend time identifying the leeway that the contractor can use, because this will have a major implication on the cost of the proposed network. Is it really necessary to cover fields? Is it acceptable to have small, isolated holes in coverage? All these things must be considered in depth.

Another major consideration is the expression of service performance as well as service coverage. Without going into detail, service performance might be described in terms of:

• Radio signal field strength
• Interference free coverage
• Digital Bit Error Rate (BER)
• Dropped call rate
• Call success rate
• Call clarity

Among many other metrics, each of which in turn must be expressed in greater detail.

It can be seen that network validation is far from simple, and it is in fact far bigger an issue than network verification, which is simply the process of measuring performance against agreed metrics. If verification appears to be a difficult process, it only highlights one thing; the network has been insufficiently specified, and this should be rectified as a matter of some urgency.

A final thought is that the complex activity of designing and implementing a radio network can only be achieved through teamwork, and this has to cross the divide between customer and contractor. This teamwork can only be achieved by trust, and trust is very much helped by a mutual understanding of the network requirements. As we have already seen, the requirements must be expressed fully in a highly detailed specification; under-specification and inadequate validation are both harbingers of doom in network design and it is this, rather than verification that must be the largest activity in the design process.