An ideal reconfigurable terminal may be considered to comprise a collection of low to high level radio and protocol (software) modules, separated by open interfaces and controlled via a reconfiguration interface. Each of these reconfigurable radio modules offers its functionality (via the open interfaces) to the system platform and, where applicable, to other, neighboring, (reconfigurable) modules. Furthermore, each of the modules has to be reconfigurable (i.e. software modules exchangeable) via this reconfiguration interface. Such a reconfigurable platform could in principle accommodate any standardized, or indeed nonstandardized, transmission scheme.
Independent of the level within the terminal protocol stack, reconfigurability may be pursued in different ways:

• using parameterized radio (and protocol) modules
• exchange of (a) single component(s) within a module
• exchange of complete radio modules or protocol layers

While external reconfiguration management ensures the overall configuration of the network, terminal reconfigureability itself falls within the scope of internal reconfiguration management. Internal reconfiguration management must control and manage the configuration and functionality of a particular network node before, during,and after reconfiguration; it also has to facilitate the compliance of the node/terminal to given transmission standards and regulations. Many different SDR terminal architectural concepts have been published and some implemented, such as:

• SPEAKeasy
• SDR Forum open terminal architecture
• the open terminal concept
• joint tactical radio system (JTRS) model

Common among all these models is that they split the terminal in (at least) two parts, one implementing the communication path (including antenna, RF, ADC/DAC, baseband, security, signaling, and basic communication applications) and the other part facilitating the configuration and reconfiguration processes within the terminal. All the models distinguish between lower and higher level functional blocks. Since each serves to implement a specific task, the single blocks may have different requirements for reconfiguration: some may be reconfigurable by parameters only; others may need ready compiled native code; while a third group of modules may be reconfigurable by interpretable byte code.

Another approach includes the development of a radio definition language (such as radio knowledge representation language (RKRL) that can be compiled after download, or may even be able to follow the Java platform model (by designing a virtual machine for radio software) with code interpretable during run time.

The source of a request for reconfiguration introduces additional complexity to the reconfiguration procedure; requests for reconfiguration may be made either from within the terminal (e.g. user, application, radio requirements, etc.) or from within the network (e.g. network, service, or application provider). Both possible originators of a request must be assigned different priorities and rights for requesting terminal/radio link reconfiguration. Reconfiguration classes describe and classify the possible effects that an intended reconfiguration process may have on the air interface. These effects may range from no change at all, to slight changes resulting in no interference to neighboring channels, to severe interference with neighboring channels. An initial classification identifies three different reconfiguration classes, summarized in the table below, along with their operational implications.

see also :

"THE ROLE OF THE CONFIGURATION CONTROL MODULE IN AN END TO END RECONFIGURABLE SYSTEM"

"Design of Generic and Adaptive Protocol Software (DGAPS)"

"Design, Implementation and Validation of a generic and reconfigurable Protocol Stack Framework for mobile Terminals"