You are here : 
Reconfigurability Cluster. Meeting 20/21 of June
Day 21st
Present
- Markus Dillinger (Siemens, TRUST)
- Parbhu Patel (Panasonic, CAST)
- Reuben Ramos (Panasonic, CAST)
- Jorge Pereira (CEU)
- Alistair Munro (Rapporteur, CEU - D2i)
- Peter Ransome (ST, PASTORAL)
PASTORAL
(http://pastoral.tilab.com/)
PR presented the PASTORAL - available on the PASTORAL web-site (and others). Inputs had been received from CAST, PASTORAL, TRUST. The report had been sent to the MIND Project Manager. The content is concerned with baseband only, not networking. Aiming for a physical demonstrator - taking a pragmatic approach.
PASTORAL does not do seamless reconfiguration: the terminal is either live or reconfiguring. Components are reused in the reconfiguration, selected according to downloaded modules (from SIM, possibly elsewhere). DSP hosts an agent to implement the SDR functions. Separate RTOS for DSP and protocol stack but some layer components can be configured to live in either.
Reconfiguration time is dominated by the search for an operational network. Download can proceed in parallel. The capability of the terminal processor is the limiting factor.
The correctness of a downloaded module must be tested. At present this is limited to integrity checking of the module data. The behaviour of the module cannot be checked without an additional test harness. It is not reasonable to expect the terminal to do this validation - responsibility of the provider of the module. A limited amount of testing against stored parameters for typical air-interfaces can be done.
What happens if the reconfiguration phase is interrupted? No user action is possible during this phase but other events may occur - loss of power, for example. All the downloaded data is retained, with a memory overhead, so the process could be restarted. At worst the terminal should not be able to register on and use a network.
The question of verifiying that a download is operationally correct is difficult to answer. The terminal and network could do a lot, or a little. Is this worthwhile? Historically there have been terminals with latent faults that have only been detected after many years of valid operation in other networks. Malicious interference with a module could introduce deliberate bad behaviour. The network has the ability to manage terminals and can reject obviously bad behaviour. Many other subversive activities are possible. Regulatory approaches may not be appropriate - good modules will survive in the marketplace.
As more possibilities emerge for programming a terminal, who owns the APIs? There are standardised approaches (such as Mexe) that define kernel and module APIs but these may be sub-optimal for a specific vendor's product. If an operator requires the use of a specific codec then this will have to be downloaded from a source approved by the manufacturer for the specific terminal.
What is the content of the download; how big is it? Typically the codec module is around 10Kbit but other components may be much larger. Quality of delivery from network to terminal will be affected by size of downloads and the rate at which they occur.
Transfers of modules between terminals can be done using SMS. This will become much easier in an all-IP network and with ad-hoc connectivity more devices will be involved.
IEEE 3G Wireless 2001 Conference Report
(http://conferences.iee.org.uk/3G2001)
400 attendees, 208 papers (50% acceptance rate). SDR papers mainly in antennas area but some also in networks/protocols areas. 8 papers on SDR overall.
Topics included: security (bi-directional in UMTS, contribution from Motorola), middleware (e.g. IP middleware concept from Nokia for reconfiguration, dynamic end-user systems, distributed functionality - mainly an application view), enabling technologies (esp. base stations where there are many new entrants), baseband issues, adaptive protocols (RWTH Aachen).
Action: MD to distribute relevant papers to attendees at the meeting
CAST
(CAST)
RR presented the architectural concepts for CAST to complement previous inputs on baseband - there were 4 including SR, SDR, the "Pereira"/"Europe" system model, and the cognitive radio (after Mitola).
SR, SDR and cognitive capability based on Mitola model - essentially a very clever terminal that can detect any active channels and configure itself to use them. CAST model is more oriented to the system model with a reasoning/intelligence function. Intelligence has two components: a user-guided part and an automated reasoning element. It can be applied to all components of the network. Reconfiguration control and functionality can be distributed in many ways. This parallels the approaches at other points for application/service optimisation - e.g. the performance enhancing proxy (PEP)approach for TCP is an example at the application level.
Decision making is separate from enabling technology. There is a similarity with decisions that must be made for resource allocation and management. There are both local decisions and global ones but information must be supplied to all decision makers. There are many AI tools that could be deployed. Data mining is the source of the information and can be distributed throughout the decision makers. Consistency of models and interpretation could be a problem for different allocation functions. CAST is implementing a small subset as a proof of principle. This includes some of the functional elements and the protocols that they communicate with.
There are some similarities in approach between TRUST and CAST. It should be possible to exploit complementarities and avoid overlaps. MD described the TRUST proposals for a "Mode Switching Process", in which complex decisions must be made for vertical handover. This is oriented towards GSM/UMTS and follows 3GPP specifications. Estimates are being made of signalling load and other operational characteristics through simulation to gain understanding of capacity issues.
Realisations of these models must take account of many non-functional issues, e.g. the impact of measurements related to signal quality - c.f. the 3GPP specified constraints on multimode terminals, measurement processes, etc. The cost/benefit is a major issue: intelligent terminals may cause excessive interference, they may be too expensive to be taken up by subscribers - e.g. if a second receiver is incorporated (according to the 3GPP model).
There are many opportunities for synergies with models from computer science or information technology, as well as opportunities for confusion. There are many possible realisations - a new revolutionary approach proposing a new system is not likely to be received well. An evolutionary model is more likely as requirements become better understood.
These are difficult and long-term issues with significant impacts on realisations - the group should monitor them for future work.
Actions and Open Items
- 5.1 Coordinators to manage use of reflector
- Project Coordinators
- 5.2 JP to request that the input be provided.
- Jorge Pereira
- 5.3 All to ensure feedback is made on the report.
- Cluster Members
- 5.4 MD to confirm availability of 3G 2001 Tutorial
- Markus Dillinger
- 5.5 JP to circulate a call for papers on the reflector.
- Jorge Pereira
- 5.6 MD to distribute papers relevant to reconfigurable radio systems from 3G 2001 to attendees at the meeting.
- Markus Dillinger