1、 Rep. ITU-R M.2117 1 REPORT ITU-R M.2117 Software defined radio in the land mobile, amateur and amateur satellite services (Question ITU-R 230/8) (2007) Page 1 Introduction 3 2 Scope 3 3 Related texts ITU-R Recommendations. 3 4 Definition 4 5 Characteristics of SDR . 4 5.1 Functional characteristics
2、 . 4 5.2 Operational characteristics 5 5.3 Technical and architectural characteristics. 6 6 Software download. 8 6.1 Security aspects 9 7 Deployment considerations 9 7.1 Vertical, horizontal industry models. 9 7.2 Timing and dependencies (business, technical) 10 8 Potential regulatory implications 1
3、1 8.1 Interference considerations. 11 8.2 Spectrum management 11 8.3 Implications for certification and conformity. 12 8.3.1 IMT-2000 technical considerations necessary to insure conformance with ITU Recommendations and Radio Regulations. 13 8.4 Implications for circulation. 13 9 SDR application to
4、specific mobile systems 14 9.1 IMT-2000 and systems beyond 14 9.1.1 User benefits 15 9.1.2 Manufacturer benefits 15 2 Rep. ITU-R M.2117 Page 9.2 Wireless access systems (WAS) including radio local area networks (RLAN). 15 9.3 Public protection and disaster relief (PPDR) 15 9.3.1 Interoperability. 16
5、 9.3.2 Enhanced functions 17 9.3.3 Remote control. 17 9.4 Intelligent transport systems (ITS) . 17 9.4.1 Space considerations 18 9.4.2 Power considerations . 18 9.4.3 Reconfiguration considerations 18 9.4.4 Service life considerations . 18 9.4.5 Cost considerations 19 9.4.6 Special requirements for
6、SDR in the vehicle . 19 9.5 Amateur and amateur satellite systems. 19 9.5.1 Soundcard applications 19 9.5.2 First-generation SDR transceiver. 20 9.5.3 Second-generation SDR transceiver 20 9.5.4 Third-generation SDR equipment 20 9.5.5 Amateur-satellite SDR applications. 20 9.6 Other land mobile syste
7、ms 20 10 Technology aspects related to IMT-2000. 20 10.1 Status of R infrared link; download from a personal computer; reconfiguration while in a battery charger; factory authorized update at local kiosks; or memory card insertion by a network operator. The ability to reconfigure an SDR radio and sy
8、stem will require protection mechanisms. The radio must be protected from being reconfigured to transmit in an inappropriate way. The radio and system should be protected from reconfiguration by individuals with malicious intent and from inadvertent reconfiguration by authorized technicians. 6 Rep.
9、ITU-R M.2117 An aspect of SDR that is important to mobile system interoperability is the SDR-enabled flexibility to allow operation with multiple air interfaces, given the use of available specifications, and across multiple RF bands. An SDR enabled portable device can be used in many different syst
10、ems by employing its capability to operate in the particular RF band and over the particular air interface that is in use by the system. This allows a user with an SDR enabled portable device to roam into various different systems and communicate with the local users on that system. When an SDR enab
11、led portable radio is used in conjunction with a system employing a cross-networking interface, a capability to communicate with local system users and remote users on other systems is established. The software in an SDR portable allows easy selection of the RF band, air interface, and group affilia
12、tion. The selection could be done automatically if the radio has policy-based or cognitive capabilities. The ability described above, to allow heterogeneous radios to communicate together by changing their air interface, could be further enabled by the following items: The air interface specificatio
13、ns are made public so that every radio vendor can implement and offer them on their radio. The software architecture(s), on which the air interfaces are built, allows air interface software developed by Company A to be used on a Company Bs radio. 5.3 Technical and architectural characteristics Consi
14、stent with the definition of SDR provided in this report, a radio is considered to be a SDR if some or all of the baseband or RF signal processing is accomplished through the use of digital signal processing software and can be modified post manufacturing. This functionality is depicted in the upper
15、 portion of Fig. 1. The air interface selection functionality, depicted in the lower portion of Fig. 1, is the control mechanism that selects the proper air interface to establish the communications and modifies the transmit/receive parameters accordingly. While this selection can be done manually,
16、two adaptive control mechanisms have been identified: policy-based or cognitive. The difference between the two resides in their approach to derive to control the proper air interface. A description of the cognitive control mechanisms which can be used for SDR can be found in Annex A. Rep. ITU-R M.2
17、117 7 FIGURE 1 Example of SDR concepts The SDR abstraction includes a full chain of base-band hardware, signal-processing, interfaces and computing elements supported by suitable RF conversion and antenna technology. The RF components may be designed specifically for the individual frequency bands o
18、f interest for the particular system implementation. However, the base-band elements conform to the standardized architecture and software interface such that the waveform application software can be directly ported to another hardware platform with similar RF capabilities. This portability of wavef
19、orm software among platforms and manufacturers is a key feature of this new generation of SDR. The base-band devices may include general purpose processors (GPP), digital signal processors (DSP) and field programmable gate arrays (FPGA) and are supported by the applications programming interface (AP
20、I) of the radio software system (SCA). The SDR may thus include traditional sequential “turing machine” software sequences as well as coded hardware functions that are optimized for the particular desired waveform. The “software” of the SDR may thus include both traditional program coding as well as
21、 logic gate coding. Systems developed that follow a standardized architecture will benefit from the economies of scale from a cross-industry user base for both hardware costs and software development. SDR systems are distinguished by following the standardized hardware and software architecture whil
22、e the programmable digital radios follow a proprietary format. At an international level, work has been done on the hardware and software architecture for a flexible SDR system, with strong interest in flexible radio systems to promote efficiency in their use of assigned channels, interoperability a
23、nd lower costs. A software architecture specification called “software communications architecture” (SCA) provides a real-time software operating-system environment to support the dynamic waveform generation and signal processing aspects of a radio 8 Rep. ITU-R M.2117 as well as the administrative a
24、spects for radio installation and change control3. Such an example of standardized architecture of hardware and software will lead to generic, flexible radio systems which may be loaded with applications to suit particular operating scenarios. They may later be reloaded and reconfigured to suit new
25、opportunities. Some SDR may be flexible enough to operate in several modes at the same time and some may be capable of changing or adding modes while continuing operation in other modes. 6 Software download Software download of air-interfaces or radio standards, in particular over the air, is one of
26、 the most important SDR topics as already mentioned above. The download of application software is not included within SDR, as that software does not directly relate to radio regulation. The download of radio software is not really a new topic in mobile phones. Due to the complexity and rapid evolut
27、ion of standards, a program code is kept in non-volatile memory and can, probably in the majority of the devices currently on the market, be reloaded or modified after manufacturing. Security mechanisms such as signed code (digital signature) are needed. It is probably in the interest of the industr
28、y to standardize this aspect up to the extent that “due diligence” in this area is clearly defined (especially relevant for horizontal market models). Since progress is also expected for security solutions, it does not make much sense to prescribe details in advance. If the adequate level of securit
29、y is assured, the method, medium and time of software download should not be of any concern from a regulatory point of view. In the context of software download, it might be useful to distinguish between downloads of code and download of air-interface parameters. Download of code may be defined as t
30、he download of the complete executable code, parameters, standard description, etc. which implements a certain air-interface standard or serves as the update or replacement of some of its modules. This feature is useful and will be extended within the next few years so as to allow for upgrades of de
31、vice capabilities. A user may, for instance, buy support for a newer version of a standard or for an additional standard. A European customer may want to upgrade his device for use in the United States of America, or vice versa, by adding new software. Operators may distribute upgrades of original m
32、anufacturer software. A variety of methods and media can be employed to this end, ranging from memory cards, CD-ROM and Internet or over-the-air download. Download of air-interface parameters may be defined as the selection from pre-defined operational modes or the re-parameterization of functionali
33、ty, relating, e.g. to transmit frequency, power, modulation, burst structure, encoding, timing, certain aspects of the protocol, etc., which can be described by parameters or templates. This does not in general require the exchange of executable code. Only a concise set of well-defined and easily st
34、andardized parameters or descriptive information has to be transmitted. In general, the radio links, download and reconfiguration management and maintenance for a terminal can be either more user-controlled or network-controlled. Potential upgrades for a terminal should be managed by the network, se
35、rvice provider and/or manufacturer based on a clear split of responsibilities. 3The SCA is not an operating system in itself, but a common set of features, interfaces and capabilities that are built on a real time operating system (RTOS). Rep. ITU-R M.2117 9 6.1 Security aspects An essential aspect
36、for the acceptance and the success of the SDR concept is the security aspect. It has to be ensured that neither the radio functionality of an SDR terminal or base station is altered unintentionally nor that unauthorized sources have access to SDR related components. As pointed out before, a secure c
37、onfiguration/reconfiguration of the terminals is seen to be feasible by cooperation of the involved parties. Nonetheless, aspects of rollback mechanisms and fault management have to be considered and developed. Regarding rollback mechanisms, it has to be ensured that after incomplete or faulty downl
38、oad of a new standard the terminal can switch back to a safe starting position. As stated in Annex C, different organizations outside ITU are currently working on secure software download aspects since it is and it will become an important topic for telecommunication devices. Since this aspect is es
39、sential and vital for all involved parties, sophisticated solutions for secure download mechanisms will be provided by the industry. Accordingly, there are technical study items regarding the assurance of security. These are examples of such study items that may facilitate secure operation: How to a
40、ssure integrity of the software, and how to prevent malicious software (malware) such as Trojan horses and computer viruses from being installed by hackers. How to protect private information. How to authenticate the identity of individuals intending to install software. How to identify the consiste
41、ncy between terminal and software. How to recover from a failure of installation. When a number of systems are installed in a terminal, there are study items regarding terminal addressing and user management: Whether every system has different addresses for identification. How to manage the address
42、resource and how to avoid duplication of addresses and shortage of the address resource. How operators gather information about the system which is installed on a terminal to use their services. It is noted that output of ITU-T Study Group 17 on security aspects is relevant to this. 7 Deployment con
43、siderations 7.1 Vertical, horizontal industry models The aspect of software download will play an important role for SDR technology, therefore, a differentiation of the diverse types of software might be useful for the discussion. Figure 2 shows a possible (rough) graduation of software present in S
44、DR terminals or base stations. As will be explained in more detail subsequently in the document, a distinction has to be made between software that has influence on or controls RF/air-interface parameters and software that has no influence on such parameters. Only radio related software needs furthe
45、r consideration. 10 Rep. ITU-R M.2117 FIGURE 2 Schematic of different types of software present in an SDR terminal or base station Due to the complexity of technology and due to security aspects there might be a stepwise SDR market evolution. In a first step the vertical model seems to be a near-ter
46、m industry model. Here “vertical” means that all hardware and software components are under responsibility of only one entity (e.g. via contracts or certification processes) which is responsible for the conformity and faultless functioning of both. This well-defined responsibility ensures that the d
47、evices will operate within the given regulatory limits. In a horizontal model the situation is quite more complex since many different independent companies will develop and offer SDR hardware and/or software components based on open interfaces. A close cooperation of all involved parties is a prere
48、quisite for a successful SDR market evolution. In particular, mechanisms have to be elaborated to ensure that the hardware of company X is compliant with the software of company Y. Before new software or hardware components are offered to the market these components have to pass through validation p
49、rocesses and have to perform test cycles successfully. It sounds reasonable that this validation process can be performed by the involved industry players self-dependently. Special security mechanisms may have to be applied to reduce the risk of unintended or criminal modification of radio functionality. For instance by using appropriate security processes, adequate safeguards from software manufacturers can be installed on hardware platforms, which can be used by those concerned to verify that the downloaded and encrypted software modules originate from the
