13 Global System for Mobile Communications (GSM) radio’s equalizer taps reflect the chan- nel multipath structure. A network might want to ask a hand- set, “How many distinguishable multipath components are you seeing?” Knowledge of the internal states of the equalizer could be useful because in some reception areas, there may be little or no multipath and 20 dB of extra signal-to-noise ratio (SNR). Software radio processing capacity is wasted running a computationally intensive equalizer algorithm when no equaliz- er is necessary. That processing capacity could be diverted to better use, or part of the processor might be put to sleep, sav- ing battery life. In addition, the radio and network could agree to put data bits in the superfluous embedded training sequence, enhancing the payload data rate accordingly. 1 Two problems arise. First, the network has no standard lan- guage with which to pose a question about equalizer taps. Sec- ond, the handset has the answer in the time-domain structure of its equalizer taps, but cannot access this information. It has no computational description of its own structure. Thus, it does not “know what it knows.” Standards-setting bodies have been gradually making such internal data available to networks through specific air interfaces, as the needs of the technology dictate. This labor-intensive process takes years to accomplish. Radio Knowledge Representation Language (RKRL), on the other hand, provides a standard language within which such unanticipated data exchanges can be defined dynamically. Why might the need for such unanticipated exchanges arise? Debugging new software radio downloads might require access to internal software parameters. Creating personal services that differentiate one service provider from another might be enhanced if the provider does not need to expose new ideas to the competition in the standards-setting process. And the time to deploy those personalized services could be reduced. Cognitive radio, through RKRL, knows that the natural lan- guage phrase equalizer taps refers to specific parameters of a tapped delay-line structure. This structure may be implemented in an application-specific integrated circuit (ASIC), a field pro- grammable gate array (FPGA), or an algorithm in a software radio. Since a cognitive radio has a model of its own internal structure, it can check the model to find out how the equalizer has been implemented. It then may retrieve the register values from the ASIC (e.g., using a JTAG port) or find the taps in the proper memory location of its software implementation. A radio that knows its own internal structure to this degree does not have to wait for a consortium, forum, or standards body to define a level H33492.x7 radio as one that can access its equalizer taps. The network can pose such an unanticipated question in (a standard) RKRL, and any RKRL-capable radio can answer it. To enable such a scenario, cognitive radio has an RKRL model of itself that includes the equalizer’s struc- ture and function, as illustrated in Fig. 1. In this example, the radio hardware consists of the antenna, the radio frequency (RF) conversion module, the modem, and the other modules shown in the hardware part of the figure. The baseband processor includes a baseband modem and a back-end control protocol stack. In addition, this processor con- tains a cognition engine and a set of computational models. The models consist of RKRL frames that describe the radio itself, including the equalizer, in the context of a comprehensive ontology, also written in RKRL. Using this ontology, the radio can track the user’s environment over time and space. Cogni- tive radio, then, matches its internal models to external obser- vations to understand what it means to commute to and from work, take a business trip to Europe, go on vacation, and so on. Clearly, significant memory, computational resources, and communications bandwidth are needed for cognitive radio, so this technology might not be deployable for some time. In addition, a collection of cognitive radios may not require human intervention to develop their own protocols. Initially, intervention will be required in order to ensure that networks of such radios remain stable (or that we know who to blame if this is not the case). Networks of such radios are complex IEEE Personal Communications • August 1999 1070-9916/99/$10.00 © 1999 IEEE A Cognitive Radio: Making Software Radios More Personal OS E P H I T OL A AND ERALD A GU I R E R OY A L NSTITUTE OF E CH N OL OGY Abstract Software radios are emerging as platforms for multiband multimode personal communications systems. Radio etiquette is the set of RF bands, air interfaces, protocols, and spatial and temporal patterns that moderate the use of the radio spectrum. Cognitive radio extends the software radio with radio-domain model-based reasoning about such etiquettes. Cognitive radio enhances the flexibility of personal services through a Radio Knowledge Representation Language. This language represents knowledge of radio etiquette, devices, software modules, propagation, networks, user needs, and application scenarios in a way that supports automated reasoning about the needs of the user. This empowers software radios to conduct expressive negotiations among peers about the use of radio spectrum across fluents of space, time, and user context. With RKRL, cognitive radio agents may actively manipulate the protocol stack to adapt known etiquettes to better satisfy the user’s needs. This transforms radio nodes from blind executors of predefined protocols to radio-domain-aware intelligent agents that search out ways to deliver the services the user wants even if that user does not know how to obtain them. Software radio [1] provides an ideal platform for the realization of cognitive radio. 1 This raises a host of questions about the control of such complex adap- tive agents, network stability, and the like.