Design Articles

Next-Generation Design Issues in Communications

If wireless devices are to communicate and interoperate autonomously, they first need to speak a common language.

By Bruce Fette PhD, Chief Scientist, General Dynamics C4 Systems; Mieczyslaw M. Kokar, PhD, Northeastern University; Mark Cummings PhD, Managing Partner enVia

Next-generation communication systems are presented with many design challenges. We are moving into an age where the rules for spectrum access may change faster than new equipment can be fielded and faster than new software for the equipment can be developed. At the same time, heterogeneity is increasing. The rate of development of new technologies and new air interface standards (AISs) is continuing to grow. Research is now exploring many new modes for finding spectrum, for negotiating for use of spectrum, for adapting the modulation to fit into available spaces, and for protocols by which radios can exchange their capabilities in this new field of Cognitive Radio and Dynamic Spectrum.

Several organizations are hard at work to lay down the necessary groundwork to support these new concepts. The Software Defined Radio Forum has established the Cognitive Radio Work Group (CRWG) and the Meta Language for Mobility Work Group (MLMWG)[1], while IEEE has set up the SCC41 committee to address related technology questions. Furthermore, there are calls for improved interoperability in public safety radios. This opens the question of how one radio might tell another radio about the communication protocols they have in common, and thus how to interoperate. [2]

figure 1
Figure 1: The SDR Forum is working with multiple industry members
to identify the requirements of next generation radio systems,
to coordinate existing and planned standards, languages and
functions that will be needed for next generation radio networks,
systems and software components. Various actors, players, and
stake holders need to communicate about issues among themselves.
The actors are shown at the outside of the figure. The issues are
shown in the middle. The intermediate layer shows some languages
that the actors could possibly use. SDR Forum is working on a
formal language with computer process-able semantics that could
be used as a common language for all this communication.

In order for Cognitive Radio applications to be built upon reasonably standardized software components, and validated stable communication signaling protocols, we need to begin to identify what messages must be exchanged between radios, and between the radios and their base station support infrastructure. We must specify standardized etiquettes and protocols that assure stable network behavior. And we must define the method by which revisions of not only software, but revisions of system control behaviors are updated to radios in the field. We need to define the protocols by which a subscriber to multiple services can interact with one or more and even perform handover amongst these services.

The analysis of these requirements revealed that in order to satisfy the dynamic nature of possible types of messages that the radios will have to exchange and “understand,” it is not possible to provide an exhaustive list of messages and protocols. Instead, we need to define the language standards that will provide the capabilities of expressing a wide variety of possible exchanges, including those that have not been anticipated at the design time of the radio equipment or software development. To achieve such a goal, the languages must have not only formally defined syntax, but also formal, computer-processable semantics. The formal syntax and semantics will enable radios to interpret any message that is expressible in the language.

The MLMWG has defined a number of use cases of Cognitive Radios, and from these use cases we will begin to define how policy, capability, etiquette and protocol are communicated amongst radio members of a network.

Our early exploratory work in this topic has considered examples of both formal languages and non-formal description languages for specific applications. The formal languages used for the use cases included such languages as Web Ontology Language (OWL) and rule languages, like Semantic Web Rule Language (SWRL). The examples of non-formal description languages include: 1) Vita Radio Transport for Analysis of RF Spectrum (VITA 49), 2) E2R Functional Description Language, and 3) various publications on use of XML as a generic means to describe capability to both human and machine. We are also closely tracking the work of IEEE SCC41 / P1900 and 802.21 activities, which are performing related work. The goal of the MLMWG is to symbiotically integrate the advantages of the descriptive languages with the formal languages so that radios not only can use the terms that are already known to domain experts, but also understand the messages formulated in the new standard languages.

Two of the first use cases developed within the SDR Forum [3] are the “London Bombing Scenario” and the “Chemical Plant Fire” [4]. This is being further evolved as a technical specification of what a CR might be expected to be able to do, and how it might be done by the CRWG and MLMWG of the SDR Forum. The use cases encompass a wide range of radios (non flexible, flexible, partially SDR, fully SDR), types of users, types of data, types of security requirements, etc. Through these use cases we quickly find the true value of a software defined radio and its flexibility to easily and rapidly respond to changes of waveform and protocol.

figure 2
Figure 2: The SDR Forum is working with multiple industry members
to identify the requirements of next generation radio systems, to
coordinate existing and planned standards, languages and functions
that will be needed for next generation radio networks, systems
and software components.

Specifically we expect the description languages to address:

  1. Hardware capabilities of the radios (Frequency bands, modulations, MAC protocols, access authorizations, etiquettes, etc.)
  2. Networks available to a user (parameters, restrictions, costs)
  3. Security/privacy (constraints, policies)
  4. Information types (QoS, Priorities)
  5. Local spectrum (spectrum activity, propagation properties)
  6. Network to subscriber control (policies)
  7. Manufacturer (Hardware and software policy)
  8. Types of users (Authority, Priority, etc.)
  9. Types of data (Async., Isoc., narrow band, broad band, etc.)

IEEE 802.21 has proposed a new standard [5] to facilitate optimization of handover between dissimilar AISs. Originally focused on Wi-Fi to WiMax, IEEE802.21 is currently working to extend it to a more general solution. This standard proposes to use some of the Semantic Web technologies—RDF for data representation and SPARQS for querying—to achieve flexibility of the possible designs.

The E2R research in the European Union has developed a Functional Description Language (FDL). FDL is an XML-like language that can be used to describe the capabilities of a radio. By parsing the XML description of the radio, the radio prepares a corresponding set of software objects, and can then schedule the execution of these objects onto corresponding processors. Since this is a non-formal language at this time, the processing of its descriptions needs to be hard coded in a procedural language that the radio would then execute.

IEEE P1900.5, now part of SCC 41[6], is completing a chartering process to work on the development of policy languages. Policy languages are commonly used to manage wired computer network resources such as routers, and thereby manage changes in network topology and performance and to suppress spam traffic and Malware. In much the same way, policy can be distributed in a wireless network to convey the most recent version of regulatory policies regarding frequency bands, power levels, modulations, and spectrum access exchanges required to access the network. This ability is important to the concept of cognitive radio, and the radio’s ability to understand what it is allowed to do to find available spectrum or connectivity, and what it is not allowed to do. For example, a radio is allowed to look for unused spectrum in the 2.4 GHz ISM band, but only up to a specified EIRP within the United States. Different rules and specifics of the frequency band edges apply in other countries. Another interesting example is the FCC 3150 MHz decision to allow communication in a band otherwise reserved for radar, when no radar user is present. So in order to be effective, a radio must not only know the local policy, but must also know which policy is the local policy. It must switch to a new local policy if the radio is moved to a new location. In other words, a radio must be able to interpret a new set of policies once they are made accessible to the radio. MLMWG is working closely with the IEEE to bring forward this important capability.

Vita Radio Transport (VRT) is another example of specifying how radio components can communicate in standardized languages within the radio. In this particular case, consider that a radio base station may be remotely located from the antenna, and that the radio waveforms are communicated to both transmit and receive over a fiber-optic cable. At a remote location, the signal is demodulated, converted to speech and the speech is transmitted over another fiber optic to a VoIP network. The communication between the RF front end and the modem back end can be performed using the VITA 49 VRT protocol. The protocol is able to describe sample rate, time stamps, beam-forming, gain, stream identifiers, and any of several sampling formats. While this specification assumes considerable distance between the RF front end and the modem at the base station, it is a proof of principle that standardized languages can be defined for communication between internal radio components, and that by doing so, we can utilize standardized software and standardized interfaces (APIs). The goal of MLMWG is to extend this capability by allowing radios to replace the standardized software with generic software that will be able to interpret and implement any communication streams expressed in a formal language.

The overall objective of the MLMWG is to work with all appropriate segments of the communications community to develop languages that meet the broadest cross section of needs possible, that are widely adopted, and can evolve to match the evolution of technologies, AISs, regulatory policies and industry needs.

In conclusion, important new capabilities are being explored in the application of SDR radios, and the groundwork is now being laid upon which exciting new capabilities that are now in planning will be built.

General Dynamics C4 Systems
Scottsdale, AZ
(480) 441-3033

Northeastern University
Boston, MA
(617) 373-2000

enVia Partners
Silicon Valley, CA
(650) 854-4406


[1] The term Meta Language should be more properly represented as a description language.

[2] M. Cummings, D. Bourse, T. Cooklev, S. Das, M. Kokar, B. Lyles, R. Normoyle, J. Strassner, P. Subrahmanyam, “IEEE 802.21: The Leading edge of a larger Challenge”, submitted to IEEE Communications Magazine, Jan 2008.

[3] You can find out more about the activities of the SDR Forum at

[4] These use cases were originally offered by Dr. Joe Mitola, and were subsequently evolved by the Public Safety SIG lead by Fred Frantz with participation by many other contributors from the SDR Forum.

[5] IEEE P802.21/D9.0 February 2008, Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services”, currently under ballot in IEEE standards activities.

[6] To understand the relationship of these two organizations, SCC41 is focused on Standards for Dynamic Spectrum Access Networks, while SDR Forum is focused on promoting the success of next-generation radio technologies. Thus there is motivation for these organizations to collaborate.

This article originally appeared in the March, 2008 issue of Portable Design. Reprinted with permission.

Digg Reddit Stumble Upon Facebook Twitter Google BlinkList Technorati Mixx Windows Live Bookmark MySpace Yahoo Bookmarks Diigo

Insert your comment

Author Name(required):

Author Web Site:

Author email address(required):


Please Introduce Secure Code: