WO2016028086A1

WO2016028086A1 - Method and terminal device for executing radio application

Info

Publication number: WO2016028086A1
Application number: PCT/KR2015/008665
Authority: WO
Inventors: 최승원; 금동현; 김용; 김경훈
Original assignee: 한양대학교 산학협력단
Priority date: 2014-08-20
Filing date: 2015-08-19
Publication date: 2016-02-25

Abstract

A method and terminal device for executing a radio application is disclosed. The method for executing a radio application is a method for executing a radio application independent of a modem in a terminal device, comprising the steps of: communicating with each other using a reconfigurable radio frequency interface (RRFI) by a unified radio application (URA), which operates on a radio computer of the terminal device, and a radio frequency (RF) transceiver, which operates in a radio platform on the radio computer; and supporting, by the RRFI, at least one service among a spectrum control service, a power control service, an antenna management service, a transmission/reception chain control service, and a radio virtual machine protection service.

Description

Method and terminal device for executing a radio application

The present invention is a software defined radio (SDR), digital wireless communications (digital wireless communications), a radio processor (RP, Radio Processor), an application processor (AP), or a multi-radio application The present invention relates to a method for executing a radio application in a mobile device and a terminal device thereof.

In particular, the present invention relates to a structure of a reconfigurable radio frequency interface (RRFI) for controlling a radio application (RA), and more particularly to a hardware-independent multi-radio application. The present invention relates to a structure of a terminal device including a reconfigurable RF interface for controlling execution of a radio application and a method of executing a radio application using the reconfigurable RF interface.

As communication technology develops, many new kinds of radio communication technologies are used according to user's preference and purpose. Most wireless communication technologies, such as Long Term Evolution (LTE), Long Term Evolution (LTE-A), Wideband Code Division Multiple Access (WCDMA), Mobile WiMAX, and Global System for Mobile Communications (GSM), The base station runs on the terminal while interacting.

The modem inside the terminal has unique commands for each manufacturer and implements each radio communication technology. In order for radio applications to control a modem, it is necessary to understand the unique commands of the modem and to develop and apply a module according to the manufacturer or model. This results in some radio applications running only on specific manufacturers' terminals or specific modems. To solve this problem, different control commands for different types of modems must be included in all radio applications, or different executable files must be created and distributed for each modem.

However, it is virtually impossible to create a radio application that can be operated in all terminals because this method requires a separate optimization task for the hardware of various modems on the market. In addition, there is a problem in the existing technology that requires a huge manpower and cost to produce a multi-radio application.

In order to solve such a problem, there are attempts to create a hardware independent multi-radio application, but to control this, each user must use a unified command rather than a manufacturer-specific command.

In other words, there is a need for a technology that changes the method of supporting high frequency (HF, High Frequency) to hardware in a wireless base station and a terminal in software form. Software Defined Radio (SDR) is a radio for economically providing services regardless of location or time to one terminal in a multi mode, multi band, and multi environment wireless communication environment. Communication technology aims to provide wireless devices and services by operation of software.

Incorporating software-defined radio modules into portable devices such as mobile phones, personal digital assistants (PDAs), and notebook computers, it is possible to simultaneously support two different frequency bands and two or more systems in one device. The SDR is a technology that can provide a new communication method for various wireless networks, various wireless communication methods, different frequency bands and high-speed data communication in the 4th generation communication pursuing all-IP based wireless multimedia communication.

In relation to software defined radio technology, there is a de facto standard technology called Software Communication Architecture (SCA). It is a collection of conventions related to the framework, middleware, and real-time operating systems required for software-defined radios, ensuring interface compatibility between software-defined radio systems. The core of the SCA is the framework framework, the core framework, which allows you to componentize each part of a radio application and reuse and combine these components to create a new radio application.

In the case of SCA, recombination is possible only with blocks pre-installed in the terminal, but user-defined blocks for use in a specific radio application cannot be installed in SCA compatible terminals having different hardware configurations. Therefore, it is not possible to use it on all SCA compatible terminals with a single executable.

This means that optimized executables must be created and distributed individually according to the hardware specifications of all SCA-compatible terminals. This causes a lot of time and cost, making commercial use of radio applications very difficult. In addition, SCA-compatible terminals do not provide a baseband application programming interface (API) for the implementation of radio applications, making it difficult to utilize selective hardware acceleration.

An object of the present invention for solving the problems of the prior art is to provide a terminal device for executing a hardware-independent radio application.

Another object of the present invention is to provide a method for executing radio applications independently of hardware by separating hierarchically various components operating in a processor in a terminal device and allowing each component to interact.

A terminal device according to an embodiment of the present invention for achieving the above object includes an application processor and a radio computer, in the terminal device for executing a radio application (RA), the integrated radio application and the RF transceiver It may be configured to include a reconfigurable radio frequency interface (RRFI) to interact.

According to another aspect of the present invention, a method for executing a modem-independent radio application in a terminal device using a baseband application programming interface, comprising: an integrated radio application (URA) operating on a radio computer of the terminal device; Radio frequency (RF) transceivers operating on a radio platform on a radio computer communicate with each other using a reconfigurable radio frequency interface (RRFI), and the RRFIs operate on spectrum control services, power control services, and antenna management services. A method of executing a radio application is provided, the method including supporting at least one service of a transmission / reception chain control service, and a radio virtual machine protection service.

Here, at least one or more services supported by the RRFI may be different depending on the reconfiguration class of the terminal device.

Here, the RRFIs can be arranged in parallel or complementary with other RF interfaces that define the physical interconnection between the baseband of the terminal device and the radio frequency integrated circuit.

Here, the RRFI may provide a first interface for configuring the RF transceiver. The first interface may support at least one of a radio application and an RF transceiver corresponding to one of a plurality of radio applications of the integrated radio application according to a radio spectrum environment to change control and data information therebetween.

Here, the RRFI may provide a seventh interface for the integrated representation of the control information. The seventh interface may support that control information via the RF front end connected to the RF transceiver is expressed in an integrated format for handling of the RF front end.

Here, the RRFI may provide an eighth interface for the integrated representation of the data payload. The eighth interface may support data payloads passing through the RF front end connected to the RF transceiver to be expressed in an integrated format for data handling of the RF front end.

Here, the RRFI may provide a ninth interface for selecting an RF protection class. RF protection classes are introduced to trade off between certification or recertification efforts and RF front-end flexibility connected to the RF transceiver, and RF front-end flexibility includes band selection, bandwidth selection, out-of-band emission limiting, or a combination thereof. can do.

Here, the RRFI may provide a second interface for extending the multi-antenna system, and the second interface may support the radio application to select the number of physical input antennas or output antennas according to a wireless environment.

Here, the RRFI provides a third interface for multi-frequency band capability, and the third interface can support a plurality of radio applications using separate frequency bands.

Here, the RRFI may provide a fourth interface for reconfiguration of the RF transceiver, and the fourth interface may support the RF transceiver to manage one or more output signals or received signals from or to one or more radio applications.

Here, the RRFI may provide a fifth interface for interoperation of radio resources, and the fifth interface may support a plurality of radio applications to share radio resources.

Here, the RRFI provides a sixth interface for testing wireless equipment, the sixth interface supports a test mode having test capability of the RF path without radiating radio waves, and the test mode is a transmission chain connected to the RF transceiver. It may include a loopback mode connected to the receive chain.

Here, RRFI is based on an extension of classes of radio computers, where radio computer classes are measured by radio control (RCMeasurements), radio controller configuration (RCConfiguration) and its subclasses, channels and their subclasses and radio control capabilities ( RCCapabilities).

Here, the RRFI may be connected to each of a radio virtual machine software component and a baseband implementation integrated circuit of the baseband processing apparatus of the terminal device and the chain of the RF transceiver chain or the RF front end.

According to another aspect of the present invention, there is provided a terminal device having an application programming interface and executing a modem independent radio application, comprising: an integrated radio application (URA) operating on a radio computer of the terminal device; A radio frequency (RF) transceiver operating on a radio platform on a radio computer; A reconfigurable radio frequency interface that interconnects URA and RF transceivers and supports at least one of spectrum control services, power control services, antenna management services, transmit / receive chain control services, and radio virtual machine protection services; RRFI), a terminal device is provided.

Here, the RRFI may support at least one or more different services according to the reconfiguration class of the terminal device.

Here, the RRFI may be arranged in parallel or complementary with a digital interface or other radio frequency interface defining a physical interconnection between the baseband of the terminal device and the radio frequency integrated circuit.

Here, the terminal device is a baseband processing device including a radio virtual machine software component for selecting radio frequency and radio virtual machine protection classes and an integrated circuit of a baseband implementation, and an RF physically connected to the baseband processing device via a digital interface. It may further include a front end chain or an RF transceiver chain. Each of the radio virtual machine software components and baseband implementation integrated circuits and the RF front end chain or RF transceiver chain may communicate with each other using RRFI.

Here, the spectrum control service may include operations of center frequency setting, bandwidth setting, and sampling rate setting.

Here, the RRFI may include a first interface for spectrum control service. The first interface sends a message requesting the center frequency setting from the URA to the RF transceiver, requesting the bandwidth setting, or requesting the sampling rate setting, confirming the center frequency setting from the RF transceiver to the URA, confirming the bandwidth setting, or setting the sampling rate. A message may be sent to confirm the response, to respond to the failure of the center frequency setting, to answer the failure of the bandwidth setting, or to fail the sampling rate setting.

Using the method and terminal device for executing a radio application according to the present invention as described above, it is possible to install and use a variety of radio applications in the terminal device independently of the hardware platform of the terminal device.

In addition, in terms of mobile operators, it is possible to convert terminals having various radio platforms used by their network subscribers to a desired communication network standard as needed, thereby enabling flexible network operation.

In addition, when a user needs to switch to a new communication network, the user can use a new communication network by simply downloading a radio application package and installing the radio application on his or her own terminal, without having to purchase a new terminal.

FIG. 1 is an exemplary diagram for explaining a case of downloading a radio application package distributed in an on-line app store in a terminal device according to an embodiment of the present invention.

2 is a block diagram illustrating a software architecture of a terminal device according to an embodiment of the present invention.

3 is a conceptual diagram illustrating four interfaces associated with a terminal device in a usage environment of the reconfigurable terminal device according to an embodiment of the present invention.

4 is a conceptual diagram illustrating that an integrated radio application and an RF transceiver are interconnected using RRFI in a reconfigurable terminal device according to an embodiment of the present invention.

FIG. 5 is a UML diagram of elements of RRFI in the terminal device of FIG. 4.

6 is a block diagram schematically illustrating the architecture of a terminal device according to the present embodiment.

FIG. 7 is a diagram illustrating a Unified Modeling Language (UML) class diagram of a radio computer related to a reconfigurable radio frequency interface (RRFI) in a method of executing a radio application of a terminal device according to another embodiment of the present invention.

8 is a block diagram illustrating an overall architecture of reference points for a terminal device according to an embodiment of the present invention.

FIG. 9 illustrates an example of reference points for installing / uninstalling a radio application and creating / deleting an instance of the radio application in the terminal device of FIG. 8.

FIG. 10 is an exemplary diagram for describing an example of reference points for obtaining a list of radio applications in the terminal device of FIG. 8.

FIG. 11 is an exemplary diagram for describing examples of reference points for activating / deactivating a radio application in the terminal device of FIG. 8.

FIG. 12 is an exemplary diagram for describing an example of reference points for delivering context information in the terminal device of FIG. 8.

FIG. 13 is an exemplary diagram for describing an example of reference points for generating a data flow and transmitting and receiving user data in the terminal device of FIG. 8.

14 is a block diagram illustrating a software architecture of a radio computer in a terminal device according to an embodiment of the present invention.

15 is a hierarchical structure diagram illustrating an example of an operation structure of an integrated radio application in a terminal device according to an embodiment of the present invention.

16 is a hierarchical structure diagram illustrating another example of an operation structure of an integrated radio application in a terminal device according to an embodiment of the present invention.

17 is a conceptual diagram illustrating functional block library implementations of a radio platform of a terminal device according to an embodiment of the present invention.

18 is a block diagram illustrating a configuration example of a radio application package that may be employed in a terminal device according to an embodiment of the present invention.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. In describing the drawings, similar reference numerals are used for similar elements.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related items or any item of a plurality of related items.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Brief definitions of terms generally used to describe the present invention are summarized. Terms other than those provided below are provided in the appropriate parts of this specification.

Radio Application (RA): An application for providing a radio communication environment that is independent of a specific hardware configuration of a terminal device and a user application. The radio application may be configured to operate on two processors by operating on a radio processor or consisting of a radio processor execution portion and an application processor execution portion. The radio application consists of a radio controller and functional blocks. Function blocks may include standard function blocks and user-defined function blocks.

Radio Application Package (RAP): A distribution form of a radio application, which includes pipeline configuration metadata along with a radio controller and functional blocks that are components of a radio application. In addition, the radio application package may additionally include a radio library.

Standard Function Block (SBF): Standard function blocks are standard function blocks in which the function of each block and the name of a function for executing the block are standardized. The standard functional block will be a collection of standard functional blocks implemented by the hardware manufacturer when the radio platform chip vendor manufactures the standard functional block and may be provided with the driver. Standard functional blocks may be implemented using a dedicated hardware accelerator, or may be implemented in executable code that runs in the core of a radio processor. When implemented with executable code that operates in the core of the radio processor, the radio library may be referred to as a radio library. Standard function blocks have a standardized name and function for each function and can be defined by a standard radio library header file.

User Defined Function Block (UDF): Function blocks that can be provided by a radio application provider when it is not provided as a standard function block or when there is a need to further customize a function existing as a standard function block. It can be implemented to run on the core of the radio processor. User-defined function blocks can be provided in executable code, source code, or intermediate representation.

User Defined Function Block (UDFB) set: A set of user defined function blocks provided by a radio application provider.

Radio HAL (Hardware Abstract Layer): A layer that abstracts many types of HW from the OS's point of view. The standardized abstraction accelerator interface is hardware independent, but the HAL makes the operating system accessible to all hardware. Similar to the role of a driver, but unlike drivers that change as hardware changes, HAL is included in the OS.

Radio Platform Driver: Software required by the OS to recognize the hardware. It is a command of OS independent of hardware. It is software to match hardware command system with each other and can act as general hardware driver.

Radio Platform: May be part of mobile device hardware for RF functionality, such as fixed and / or programmable hardware accelerators, RF transceivers, antennas. That is, the radio platform may be part of hardware capable of generating or receiving RF signals. In essence, the radio platform may be heterogeneous hardware that includes, for example, fixed accelerators such as ASICs or other processing elements such as reconfigurable accelerators such as FPGAs. .

Radio Computer: A collection of radio processors (RPs) and radio platforms within a reconfigurable mobile device (MD). In mobile devices, individual radio applications can be designed as software components running on a radio processor that can be viewed as a more general purpose computing element.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, the same reference numerals are used for the same elements in the drawings and redundant descriptions of the same elements will be omitted.

FIG. 1 is an exemplary view illustrating a case of downloading a radio application package distributed in an on-line app store in a terminal device according to an embodiment of the present invention.

Referring to FIG. 1, the terminal device according to the present embodiment may download and install a radio application in various wireless network environments. That is, the user accesses the online app store 20 using the terminal device 10, selects a desired radio application from a list of radio applications supporting various wireless communication schemes provided by the app store, and selects the corresponding radio application. You can download the included radio application package.

Various wireless schemes may include Longterm Evolution (LTE), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile Communications (GSM), Radio-Frequency Identification (RFID), and the like. . The user can download and install a plurality of radio applications on his terminal and freely execute necessary radio applications according to the situation.

Configuration and Software Architecture of Radio Applications

Referring to FIG. 2, a radio software architecture of a terminal device according to the present embodiment may include an application processor layer operating on an application processor (AP) and a radio processor layer operating on a radio processor (RP). Can be. The radio processor may be referred to as a baseband processor (BP). The combination of radio processor and radio platform may be referred to as a radio computer.

2 illustrates a software architecture environment in which a Radio Control Framework (RCF), which will be described later, is divided into an application processor execution portion and a radio processor execution portion to operate on two processors. Of course, the radio control framework can be implemented to run on a radio processor or radio operating system (OS).

Non-real time operating systems (OS) such as Google's Android OS and Apple's iOS run on the application processor, or radio OS on the radio processor. The real time operating system (Real time OS) may be operated. Hereinafter, for the sake of clarity, the non-real time operating system operating in the application processor layer is referred to as an 'operating system (OS)', and the real time operating system operating in the radio processor layer is referred to as 'real time OS'. Operating system (Radio OS).

Hereinafter, components constituting the application processor layer, the radio processor layer, and the radio control framework will be described in detail.

Application processor layer

As illustrated in FIG. 2, the application processor layer may include components such as a driver, an operating system (OS), and a communication service layer.

The driver runs hardware devices on a given operating system. Hardware devices may include cameras, speakers, and the like.

The operating system may include a non-real time OS operating on a typical mobile device such as Android, iOS. When the radio control framework is configured to run on an application processor and a radio processor, there may be an application processor layer execution portion of the radio control framework on the operating system.

The communication service layer may provide at least some of the three services described below to the radio control framework.

The first service is an administrative related service, which is related to installing / uninstalling a radio application, creating / deleting an instance, and obtaining a list of radio applications regarding status of installation, instance, and activity. .

The second service is a service related to access control, which is related to launching / deactivating a radio application, creating a data flow, creating a network assignment, and obtaining a list of radio applications for each installation, instance, activity, and the like.

Finally, the third service is a service related to data flow, which is related to sending and receiving user data.

As one example of a communication service layer configuration for providing at least some of the three services described above, the communication service layer may include an administrator application, a mobility policy manager, a networking stack, and a monitor ( It may be implemented as at least one or more applications including at least a portion of the monitor. The networking stack may include a protocol stack that operates at the communication service layer.

Meanwhile, the communication service layer may include only some of the above-described components or may include additional components other than the above-described components. Also, components incorporating functions of at least two or more of the aforementioned components may be included in the communication service layer. In addition, the above-described components are merely examples of the components that the communication service layer should have in order to support the services that the communication service layer should perform. That is, the communication service layer is defined by the role that the communication service layer plays, and the configuration of the communication service layer is not limited by the above-described components.

In the configuration in which the radio control framework operates in the application processor and the radio processor, the radio applications that are the targets of the method for distributing, installing, and executing the terminal device according to the present embodiment are respectively an application processor layer execution part and a radio processor layer execution part It may consist of. The Radio Controller (RC), the execution part of the application processor layer of a radio application, is responsible for sending context information to the monitor of the communication service layer or exchanging data with the networking stack of the communication service layer. Can be performed.

Radio processor layer

The radio processor layer includes components such as a radio operating system and a radio platform driver as shown in FIG.

The radio operating system (OS) is a real time operating system. When the radio control framework is configured to run on an application processor and a radio processor, there may be a radio processor execution portion of the radio control framework on the radio OS.

The radio platform driver is a component required by the radio OS to recognize a hardware radio platform like a general hardware driver.

If the radio control framework operates only on a radio processor (see FIG. 3), reconfigurable radio applications targeted for distribution, installation, and execution to a terminal device according to the present embodiment may operate at a radio processor layer.

A radio controller (RC) of each radio application plays a role of sending context information to a monitor of a communication service layer or exchanging data with a networking stack of a communication service layer.

The above-described radio processor may configure a radio computer together with radio platform or radio platform hardware. Here, Radio Platform Hardware may generally be comprised of programmable hardware and baseband accelerator (s) of a radio processor. Baseband accelerators prepared for standard functional block (s) can often be provided in the form of an application-specific integrated circuit (ASIC). The radio platform may also include an RF transceiver and an antenna.

A multiradio interface (MURI) may be disposed between the aforementioned communication service layer and the control radio control framework, and a unified radio application interface (URAI) between the radio control framework and the unified radio application. Can be arranged. In addition, a reconfigurable RF interface (RRFI) may be disposed between the integrated radio application and the RF transceiver.

The radio application is an application that enables communication of a mobile terminal and may be distributed in the form of a radio application package (RAP). The radio application package may include components of a function block (FB), pipeline configuration metadata (data metadata), radio controller code (RC code), and a radio library.

The radio library may be distributed together with the executable code in the radio application package when the standard functional block is distributed in the executable code form. The radio application package may be downloaded to the OS of the application processor layer, and may be configured with configcodes. The radio library may be loaded into the radio OS of the radio processor layer through a process of loading from the application processor to the radio processor by referring to the pipeline configuration metadata.

Radio control framework

Radio Control Framework (RCF) is a component that provides an operating environment for radio applications.

If the radio control framework is a configuration that runs on an application processor and a radio processor, the radio control framework can be divided into two groups. That is, one group runs on an application processor and the other group runs on a radio processor. Which components of the radio control framework run in real time (on a radio processor) and which components run non-real time (on an application processor) can be determined differently by each vendor.

The Radio Control Framework (RCF) can basically be configured to manage radio application (s), including at least some of the following five components.

However, the radio control framework may include only some of the five components described below, or may further include components other than the five components. Alternatively, the radio control framework may consist of components incorporating the functionality of at least two or more components described below. The function and role of the radio control framework are defined by the functions performed by the components described below, and the configuration of the radio control framework is not limited by the exemplary components described below. That is, the radio control framework may have various configurations for performing at least some of the functions of the components described below.

Configuration Manager (CM): Install / uninstall a radio application for a multi-radio terminal device, create / delete an instance and manage access to radio parameters of the radio applications.

Radio Connection Manager (RCM): Activation / deactivation of radio applications according to user needs and overall management of user data flows that can be switched from one radio application to another.

Flow Controller (FC): Sending, receiving, and controlling flow of user data packets.

Multiradio Controller (MRC): Schedules requests for radio resources raised from concurrently running radio applications in order to detect interoperability problems between radio applications in advance.

Resource Manager (RM): Management of multi-radio resources for sharing multi-radio resources between active radio applications while meeting real-time requirements.

Software Architecture of Reconfigurable RF Interfaces

3 is a conceptual diagram illustrating four interfaces associated with a terminal device in an environment of using a reconfigurable terminal device according to an embodiment of the present invention.

Referring to FIG. 3, a reconfigurable mobile device according to the present embodiment can simultaneously execute multiple / multiple radios and configure radios by a new radio application package (RAP). Can be changed. All radio applications (RAs) may be referred to as Unified Radio Applications (URAs) when they exhibit common attributes or characteristics in terms of requirements related to radio reconfiguration of the mobile device.

In order to run multiple / multiple integrated radio applications, a reconfigurable mobile device (hereinafter referred to simply as mobile device) is a communications services layer (CSL), a radio control framework (RCF), a radio platform. (Radio Platform) and four sets of interfaces for their interconnection.

Four interfaces related to the reconfigurable mobile device (MD) according to the present embodiment are a multi radio interface (MURI), which is an interface between each component of the communication service layer and each component of the radio control framework. ), The Reconfigurable Radio Frequency Interface (RRFI), an interface between the Unified Radio Application (URA) and the Radio Frequency Transceiver (RF Transceiver), and between each component of the Integrated Radio Application and the Radio Control Framework. The interface may include a Unified Radio Application Interface (URAI), a Radio Programming Interface (RPI), which is an interface related to independent and uniform production of radio applications.

Reconfigurable RF Interface (RRFI) is an interface defined between an integrated radio application and an RF transceiver. That is, the interface between the URA and the radio spectrum.

4 is a conceptual diagram illustrating an interaction between an integrated radio application and an RF transceiver using RRFI in a reconfigurable terminal device according to an embodiment of the present invention. FIG. 5 is a UML diagram of elements of RRFI in the terminal device of FIG. 4.

As illustrated in FIGS. 4 and 5, the RRFI may support at least one or more of the following five types of services. The five services are Spectrum Control Services, Power Control Services, Antenna Management Services, Tx / Rx Chain Control Services, and RVM Protection Services. Virtual Machine Protection Services).

The Spectrum Control Service is used to make spectrum-related settings for the RF Transceiver system. Different radio applications may have their own spectrum setting values. The spectrum control service may include settings of a center frequency, a bandwidth, a sampling rate, a handover parameter configuration, and the like.

For spectrum control services, the RRFI may provide a first interface. In this case, the first interface sends a message requesting the center frequency setting from the URA to the RF transceiver, requesting the bandwidth setting, or requesting the sampling rate setting, confirming the center frequency setting from the RF transceiver to the URA, confirming the bandwidth setting, A message may be sent to confirm the sampling rate setting, to respond to the failure of the center frequency setting, to answer the failure of the bandwidth setting, or to fail the sampling rate setting.

The power control service is used to make power-related settings for the RF transceiver system. For example, the power control service may include maximum Tx power level set up, Tx power per antenna set up, Receive sensitivity level set up, transmission and reception It may include gain setting (Tx / Rx gain set up), reception gain setting (Rx gain set up), monitoring of Tx power level, and the like. It may also support the setting of specific power schemes. In this case, the specific output schema may include day, night, event, power saving, and the like.

The RRFI may provide a second interface for power control service. In this case, the second interface requests the URA to the RF transceiver to set the maximum power level of the transmit chain, request the transmit power per transmit antenna, request the receive gain of the receive chain, or request the transmit power level of an active radio application. Message from the RF transceiver to URA, check the transmit power setting on the transmit chain, check the transmit power setting per transmit antenna, check the receive gain setting on the receive chain, or fail to set the maximum power level on the transmit chain. A message may be forwarded in response to, or in response to a failure in setting transmit power per transmit antenna, or in response to a failure in setting the receive gain of the receive chain. The second interface can also communicate information related to the transmit power level measurement of the active radio application from the RF transceiver to the URA.

The antenna management service may provide services related to antenna port selection and RF radiation type of the RF transceiver system. For example, antenna management services include antenna radiation pattern, antenna gain, antenna direction, sector configuration (e.g. 3x1, 1x1, etc.), physical antenna type. (Physical Antenna type, for example, Multi-pad, MIMO, SIMO, MISO, SISO, etc.) and the like.

The RRFI may provide a third interface for antenna management service. In this case, the third interface may send a message requesting the transmit antenna port selection from the URA to the RF transceiver or request the receive antenna port selection, confirm the transmit antenna port selection from the RF transceiver to the URA, or confirm the receive antenna port selection. Or respond to a failure of transmit antenna port selection or a response of failure of receive antenna port selection.

The transmit / receive chain control service may be used to provide parameters related to real-time control of the RF transceiver chain. For example, the transmit / receive chain control service may include transmit start / stop time set up, receive start / stop time set up, and update of transmit / receive chain parameters. / Rx chain parameters). In addition, the baseband signal generated by the URA may be transmitted to the RF transceiver, and the spectrum and / or power setting values that are varied during the actual communication may be controlled in real time.

The RRFI may provide a fourth interface for the transmit / receive chain control service. In this case, the fourth interface may transmit a message to the RF transceiver from the URA to request transmission start time setting, request transmission end time setting, request reception start time setting, request reception end time setting, or request transmission / reception chain parameter update. Check the transmission start time setting, confirm the transmission end time setting, check the reception start time setting, check the reception end time setting, check the transmission and reception chain parameter update, or check the failure of the transmission start time setting from the RF transceiver to URA. A message may be forwarded to respond to the failure of the transmission end time setting, the failure of the reception start time setting, the failure of the reception end time setting, or the failure of the transmission / reception chain parameter update.

The RVM protection service may provide a service for the RF transceiver system to select an RVM protection class. For example, the RVM protection service may include a selection and / or request of an RVM RF protection class, an RF front-end indication of input data modification, and the like. The RVM protection service is described in more detail as follows.

RVM protection services

In the RVM protection service of the reconfigurable radio frequency interface, an interface and a messenger related to the service will be described as follows. As part of the RRFI feature, the RVM protection service includes a selection of RF protection class, a request of RF protection class status, and a Request for change of RF protection classes. Information on RF front-end indication of modification of input data signals, RF front-end emergency switch off, and cross radio access interference (information on cross radio access technology interference).

The RF protection class selection is described as follows. In other words, in the context of software reconfiguration, the RF front end generally allows selection of RF protection classes. Appropriate protection classes may generally have software components and may affect the required level of re-authentication (declaration of conformity) of the relevant mobile device. The selection request for a particular RF protection class typically leads to an acknowledgment (ACK) issued by the RF front end in the case of a successful operation, and to the issuance of a not acknowledgement (NACK) message in the event of a failed attempt. The RF frontend may then be selected with a higher level protection class, including the required protection, even if the specific support required for the protection class is not provided. This may lead to issuance of an acknowledgment with modification (ACKM) message. As far as possible, details of the modified protection class selection may be provided upon protection request. If a request for a protection class specifically indicates that it does not choose a higher class, such as a more restrictive protection mechanism that prevents software components from functioning properly, then the specific protection class requested is not available. Low class can be selected. On the other hand, this may require a more detailed re-authentication (declaration of conformity) process because lower protection classes can lead to less protected front ends, which in turn poses a higher risk to other users.

Referring to the request of RF protection class status, other components, such as baseband and / or application processor components, may request information regarding the RF protection class status. The RF front end may then provide information as to whether the protection class mechanism is active. The activated state may include, for example, additional filters limiting out of band emissions and / or spurious emissions, limiting the maximum thrust power level, and the like.

Referring to the Request for change of RF protection classes, RF protection may be changed according to current active radio access technology. For example, if hard-wired WiFi is used so that RF protection classes are not required or they are disabled. On the other hand, when software modified LTE is used, a specific RF protection class may be required. For example, it may be required to reduce the level required for re-authentication (declaration of conformity) of the mobile device. The modification of the protection class may be performed based on a specific external trigger on the RF front end. For example, the RF front end may be programmed to be temporarily or conditionally (re) configured upon request depending on input waveform or radio access technology (RAT) data such that the RF protection class is changed to active or inactive.

Describing RF front-end indication of modification of input data signals, RF front-end protection mechanisms selected by one of the higher processors reduce output power levels, out-band signal components. When a change of the data transmission request such as truncation of the data is required, corresponding information on the output of the RF front end may be provided as a message. This can typically be handled by the baseband and / or application processor.

RF front-end emergency switch off means that if the RF front-end protection mechanism detects a large violation of emission limiting, such as large out-of-band / spurious emissions, the RF front end will stop the transmission. You can decide. On the other hand, other transmissions or simultaneous transmissions can still continue if the limits are met.

Referring to information on cross radio access technology interference, when multiple RATs are simultaneously transmitted or received, various RATs may occur with each other. When such interference is detected at the RF front end, the RF front end can provide that information to the integrated radio application, radio operating system, radio control framework, or radio computer via the RRFI.

Class definitions for interface

Each interface class related to RRFI may be defined using a UML diagram of FIG. 5 describing interface classes and a template shown in Tables 1 to 3 below. Tables 1 to 3 show operations related to interface classes for three of the interfaces for the five services described above.

Table 1

TABLE 2

TABLE 3

At least one service of the aforementioned RRFI may be implemented in the mobile device according to mobile device reconfiguration classes (MDRC). The reconfigurable mobile device may support RRFI services as shown in Table 4 below according to its MDRC. If the reconfigurable mobile device supports multiple MDRCs, the reconfigurable mobile device can support all services related to MDRC.

Here URA can be defined as part of a radio processor in a radio computer that generates a baseband signal to be transmitted in transmission and decodes the received baseband signal in reception.

In addition, a transceiver system including a transceiver chain and an antenna may be defined as part of a radio platform in a radio computer that converts a baseband signal into a radio signal for transmission and a radio signal into a baseband signal for reception. have.

A class can also be a template, a template, that defines variables and methods within a particular kind of object. Thus, an object is an instance defined by a class and can have actual values instead of variables. A class, for example, is one of the concepts that define object-oriented programming, which can have subclasses that inherit all or part of a class from its class properties, in which case the class can be a superclass for each subclass. Subclasses can define their own methods and variables, and the structure between subclasses and classes is called the class hierarchy. Methods, along with functions, subroutines, routines, and procedures, can refer to portions of code that perform specific actions in software.

Table 4

In Table 4, MDRC-0 represents the class of mobile device that cannot be reconfigured, MDRC-1 represents the class of mobile device that cannot share resources with fixed hardware, and MDRC-2 and MDRC-5 are predefined Represents a class of mobile devices with fixed resources, MDRC-3 and MDRC-6 represent classes of mobile devices with static resource requirements, and MDRC-4 and MDRC-7 are classes of mobile devices with dynamic resource requirements Indicates. MDRC-2, MDRC-3, and MDRC-4 are classes that can implement platform-specific executable code and implement RRFI. MDRC-5, MDRC-6, and MDRC-7 are platform-independent source code that can download RRFI, etc. Classes that can implement

Referring back to FIG. 4, the radio computer may generate a baseband signal to be transmitted in a transmission mode (Tx mode) and decode the baseband signal received in a reception mode (Rx mode).

In more detail, the components of a radio computer may be defined as an integrated radio application URA as part of a radio processor in a radio computer.

The RF transceiver may include at least one RF transceiver chain and at least one antenna. The RF transceiver may be part of a radio platform within a radio computer. The radio platform may convert the baseband signal into a radio signal in a transmission mode and convert the radio signal into a baseband signal in a reception mode.

RF interfaces may define physical interconnections between a baseband (eg, a modem) and a radio frequency integrated circuit (RFIC). For example, a wireless mobile RF integrated circuit (IC) may interact with the baseband IC interface of the mobile device. The RF interface may be a complementary interface used in parallel with the RRFI.

The entity, component or unit of the radio computer described above may be mapped with the system requirements for the RF transceiver of the mobile device (ie, the terminal device of this embodiment). System requirements may include a signal or message relating to a setup request, command, or request that allows the RF transceiver to select RF configuration parameters.

System requirements include the first system requirement (R-FUNC-RFT-01) for RF configuration, the second system requirement (R-FUNC-) for extensibility for multiple-antenna system. RFT-02), Third System Requirements for Capability of Multiple Frequency Bands (R-FUNC-RFT-03), Fourth System Requirements for Reconfigurability of RF Transceiver (R-FUNC-RFT) -04), the fifth system requirement on interoperability of radio resources (R-FUNC-RFT-05), the sixth system requirement on testability of radio equipment (R). -FUNC-RFT-06), the seventh system requirement for unified representation of control information (R-FUNC-RFT-07), the unified representation of data payload Eighth System Requirements (R-FUNC-RFT-08), and Selection of RF Protection Class n-th system) (R-FUNC-RFT-09).

For example, the mapping of the above-described entity, component or unit URA, RF transceiver and RRFI and system requirements of the radio computer is shown in Table 5 below. Table 5 also provides brief comments on the functionality of the mapped system requirements.

Table 5

Interface definition

Referring to FIG. 6, the terminal device according to the present embodiment includes a radio virtual machine (RVM) for baseband processing and a baseband hard-wired type of an application specific integrated circuit (ASIC), And an RF front end chain or an RF transceiver chain. Radio virtual machine software components can select RF and RVM protection classes. The baseband processing apparatus may be connected to an application processor or MAC (Layer 2) and its upper layer processing apparatus.

In addition, the terminal device may include an analog digital converter and a digital analog converter between the RF front end chain or the RF transceiver chain and the baseband processing device. Here, the analog-to-digital converter and the digital-to-analog converter may be implemented by existing interface standards such as DigRF that are not specified in the RRFI. Existing interface standards may be referred to as other radio frequency interfaces. However, the RF front end chain or RF transceiver chain and the RVM software component or baseband implementation integrated circuit are interconnected by the reconfigurable radio frequency interface (RRFI) of the present embodiment.

Information Model for Radio Computer

Radio computer classes related to RRFIs as shown in FIG. 7 are defined as follows.

The RadioComputer class describes all the resources and interfaces related to the hardware and software of a reconfigurable mobile device. For example, the RadioComputer class may include computational / spectral resource usage, collection of context information, channel measurement results, and the like. The RadioComputer class may be associated with a user class and the like through the IRRFI class.

The RCCapabilities class contains information about radio computer (RC) capabilities including hardware, software, transmission and measurement capabilities such as supported air interfaces, maximum transmit power, and the like. Each instance of the radiocomputer class may have only one instance of the RC capability class as a member.

The Channel class describes one frequency channel with or without an active connection. Each instance of the radiocomputer class may contain zero, one or several instances of the Channel class as members.

The ChannelProfile class contains general information about the frequency channel, such as channel ID, center frequency, bandwidth, and air interface used. Each instance of the Channel class may include only one instance of the ChannelProfile class as a member.

The ChannelMeasurements class may include current measurements (instantaneous measurement data and performance statistics derived from the data) related to the frequency channel, such as interference and load measurements. Each instance of the Channel class may include only one instance of the ChannelMeasurements class as a member.

The RCConfiguration class contains information about the current configuration of the radio computer. Each instance of the RadioComputer class may include only one instance of the RCConfiguration class as a member.

The Link class contains information about one active radio application and the corresponding connection between the reconfigurable radio terminal and Radio Access Networks (RANs). Each instance of the RCConfiguration class may contain zero, one or several instances of the Link class as members. Each instance of the link class may be associated with one instance of the channel class.

The LinkProfile class includes general information about an active connection such as a link identifier (link ID), a service call identifier (serving cell ID), a channel used, and the like. Each instance of the Link class may contain only one instance of the LinkProfile class as a member.

The LinkMeasurements class is the current measurement associated with the active connection, such as Block Error Rate (BLER), Power, and Signal to Interference plus Noise Ratio (SINR). Instantaneous measurement data and performance statistics derived from this data. Each instance of the Link class may contain only one instance of the LinkMeasurements class as a member.

The RFConfiguration class contains information about the configuration of an RF transceiver. Each instance of the Link class can have only one instance of the RFConfgurable class as a member.

The TxPath class describes one transmit path. Each instance of an RFConfiguration class may have zero, one or several instances of a transmission path class or a chain class as members.

Receive Path (RxPath) class describes one receive path. Each instance of the RFConfiguration class can have only one instance of the receive path class or chain class as a member.

The antenna class includes information on antenna selection. Each instance of the link class may have zero, one or several instances of the antenna class as members. The antenna class may include an antenna profile class and an antenna measurement class as subclasses.

The AntennaProfile class contains general information about the antenna, such as an antenna identifier (ID). Each instance of the antenna class may include only one instance of the antenna profile as a member.

The AntennaMeasurments class may include current measurements related to the antenna, such as gain measurements, that is, instantaneous measurement data and performance statistics derived from this data. Each instance of the antenna class may have only one instance of the antenna measurement class as a member.

The RCMeasurements class may include current measurements associated with the reconfigurable wireless terminal, that is, instantaneous measurement data and performance statistics derived from this data, such as battery capacity or terminal location measurements. Each instance of the radiocomputer class may have only one instance of the RFMeasurements class as a member.

Class Definitions for Information Model

Each class of the above-described radio computer may be defined using the Unified Modeling Language (UML) diagram of FIG. 7 describing the relationship between all classes of the radio computer and a predetermined template as shown in Tables 6 to 21 below. have. In addition, Tables 6-21 illustrate the relevant operation of radio computer classes.

Table 6

TABLE 7

Table 8

Table 9

Table 10

Table 11

Table 12

Table 13

Table 14

Table 15

Table 16

Table 17

Table 18

Table 19

Table 20

Table 21

Software Architecture Reference Points

The following description is examples of interfacing procedures and interfaces between a radio control framework and a radio application for realizing installation / uninstallation, creation and deletion of instances, and operation of an integrated radio application.

In FIG. 8, the RF layer 710 includes an RF transceiver (RF XCVR with Antennas) 711 to which an antenna is connected, the radio application layer 720 includes a URA 125, and the radio control framework 730 It includes a configuration manager (CM, 731), a radio connection manager (RCM, 732), a flow controller (FC, 733), a multi-radio controller (MRC, 734) and a resource manager (RM, 735), the communication service layer 740 ) Includes an administrator (Admin) 741, a mobility policy manager (MPM, 742), a networking stack (N / W stack, 743), and a monitor (744).

The solid lines between the two blocks (CF1, CF2, CF3, CF4, CF5, CTRL1, CTRL2, DCTRL1, DCTRL2, DCTRL3, CII) are defined reference points between the two blocks, Refers to the reference point being performed. Meanwhile, a dotted line between two blocks refers to a reference point performed by interaction through a radio operating system based on a command issued by a corresponding block. As described below, the blocks of the RCF, such as the configuration manager (CM), the radio connection manager (RCM), the multiradio controller (MRC) and the resource manager (RM), are commands that enable interaction in the URA through the radio operating system. Issue a.

Each reference point is defined by three types of interfaces: multiple radio interfaces (MURI) and interfaces between components of the radio control framework and components of the communication service layer. It is based on Unified Radio Applications Interfaces (URAIs), which are interfaces between components of the Radio Application and the Radio Control Framework, and Reconfigurable Radio Frequency Interfaces (RRFIs), which are interfaces between integrated radio applications and RF transceivers. In addition to the interfaces belonging to MURI, URAI and RRFI, the interfaces between components of the RCF are also defined as reference points. In the present embodiment, the reference points may be classified according to the procedure of each function so that the classification for each reference point corresponds to the operation procedure described later.

Reference Point 1: Radio Of application install (install) / Uninstall (uninstall) and Instance interfaces for creating / deleting

Referring to FIG. 9, in CF1a, an administrator 741 instructs the configuration manager 731 to install and uninstall a radio application, or the manager 741 requests a request from the CM 731. An interface between a manager and a configuration manager for receiving a response.

The CF2a may be configured to allow mobility policy manager 742 to request configuration manager 731 to create or delete an instance of a radio application, or for mobility policy manager 742 to receive a response to the request from configuration manager 731. Interface between policy manager and configuration manager.

The CF4 requests the configuration manager 731 to transmit parameters related to radio resources by the multiradio controller 734 during the creation procedure of the radio application instance, or the configuration manager 731 requests the radio resource. Interface between a configuration manager and a multiradio controller for receiving a response to a request for parameters associated with the network.

The CF5 requests the resource manager 735 to transmit parameters related to computational resources by the configuration manager 731 during the creation procedure of the radio application instance, or the configuration manager 731 requests the request. It is an interface between a configuration manager and a resource manager, for receiving a response to a request for parameters related to computational resources.

Reference Point 2: Radio Of applications List Check Interfaces

Referring to FIG. 10, the CF1b requests the manager 741 to transmit a list of radio applications to the configuration manager 731, or the manager 741 responds to a request from the configuration manager 731, that is, the radio application list. An interface between a manager and a configuration manager for receiving a response to a request.

The CF2b requests the mobility policy manager 742 to transmit the radio application list to the configuration manager 731 or the mobility policy manager 742 responds to the request from the configuration manager 731, that is, the request of the radio application list. An interface between a mobility policy manager and a configuration manager for receiving a response.

Reference Point 3: Radio Of application Interfaces for Activation / Deactivation

Referring to FIG. 11, the CTRL1a requests the mobility policy manager 742 to request a radio connection manager 732 to perform activation or deactivation of a radio application, or the mobility policy manager 742 may request a radio connection manager 732. Interface between the mobility policy manager and the radio connection manager for receiving a response to the request.

Reference Point 4: Interfaces for Transferring Context Information

Referring to FIG. 12, the CII requests that the monitor 744 transmit the context information to the radio controller part 721 of the radio application of the radio application, or the monitor 744 requests the request, that is, the request for the context information. Interface between the monitor and the radio controller for receiving a signal from the radio controller of the radio application.

The contextual information is generated in the corresponding functional blocks of the radio applications and communicated to the radio controller of the radio application. There must be interfaces between the radio controller inside the radio applications and each of the corresponding functional blocks. This means, in particular, that a baseband interface (BBI) must be defined for transferring context information between the radio controller and its corresponding functional blocks.

Reference Point 5: Interfaces for Creating Data Flows and Sending and Receiving User Data

Referring to FIG. 13, the CTRL1b requests the mobility policy manager 742 to request the radio connection manager 732 to establish a data flow or network association with a peer equipment, or the mobility policy manager 742. Is an interface between the mobility policy manager and the radio connection manager for receiving a response to the request from the radio connection manager 732.

CTRL2 allows radio connection manager 732 to request flow controller 733 to form a data flow or radio connection manager 732 to receive a response to the request from flow controller 733. It is an interface between the manager 732 and the flow controller.

DCTRL1 is an interface between the flow controller and the networking stack for the flow controller 733 to receive or transfer user data to or from the networking stack for data transmission and reception procedures. DCTRL1 may also include acknowledgment of the completion of the data transfer with respect to transmit user data from flow controller 733 to networking stack 743.

DCTRL2 is a flow controller for requesting flow controller 733 to transmit user data to radio application 720 or to transmit radio user 720 information of transmit user data, such as throughput, data bandwidth, and the like. Interface between radio applications. DCTRL2 is also used by flow controller 733 to receive a response to the request from the radio application 720. In the case of data reception, the DTRCL2 interface is used to deliver receive user data from the radio application 720 to the flow controller 733.

DCTRL3 is an interface between a radio application and an RF transceiver for the radio application 720 to receive or transmit received / transmitting user data from an RF transceiver (XCVR) with an antenna or to an RF transceiver with an antenna.

Software Architecture of the Radio Processor Layer

In the following, when the above-described radio application operates in a radio processor layer, a more detailed description of its operation structure is provided.

Once the radio application package is downloaded, custom function block codes and radio libraries that must be operated at the radio processor layer are installed so that they can be accessed at the radio processor layer.

Codes for configuring elements that should be operated in the radio processor layer are defined as configuration codes (abbreviated as 'configcode' or 'configcode') including the above-described user-defined function block codes. Configcode can include only user-defined function block codes or a radio library with user-defined function block codes, depending on the situation. Configcode may take the form of executable code or intermediate representation (IR).

In addition, hereinafter, a real radio platform is defined as a target radio platform, and a concept of a shadow radio platform is defined as a virtual medium having a hardware abstraction for the target radio platform. The shadow radio platform may mean a radio platform virtualized by a developer of a radio application as an operating environment of a radio application. For example, the shadow radio platform of the radio application may be the same as the target radio platform and may be different from the target radio platform. When the shadow radio platform is different from the target radio platform, the shadow radio platform can be understood as a hardware independent virtual device in a concept corresponding to the actual target radio platform. Therefore, the shadow radio platform is a radio virtual machine (RVM). Can be

If the shadow radio platform is different from the target radio platform, and the shadow radio platform becomes a radio virtual machine, the radio virtual machine performs a virtualization function to allow the above-described configcodes to operate on the actual target radio platform, and in implementation, configcode It may be a back-end compiler that provides a just-in-time (JIT) or overhead-of-time (AOT) method of compiling them into executable code of a target radio platform.

14 is a block diagram illustrating a software architecture of a radio computer according to an embodiment of the present invention.

The radio computer provides communication capabilities to the mobile device, and its software architecture may comprise the following components.

-Radio OS

Radio processor execution part of the radio control framework

If the Shadow Radio Platform is a Radio Virtual Machine (RVM), implementation of the Radio Virtual Machine (implementation)

Native implementation of the Radio Lib if the shadow radio platform is a radio virtual machine

Configuration codes (configcodes) of radio applications (RAs), configuration codes may be provided in the form of executable code of the target radio platform or platform independent intermediate representation (IR).

If the shadow radio platform is a radio virtual machine, Configcode is interpreted by the radio virtual machine, and if the shadow radio platform is a target radio platform, Configcode is the executable code that can be run directly on that target radio platform. .

RCF and its interfaces, MURI (MUltiRadio Interface) and URAI (Unified Radio Application Interfaces), are as described above.

The shadow radio platform may be a radio virtual machine or a target radio platform.

If the shadow radio platform is the same as the target radio platform, the front-end compiler will generate the executable code for the target platform and the configcodes are equivalent to the executable code for that particular platform.

The radio virtual machine is an abstraction machine that can run configcodes and is independent of any hardware. Configcode runs on the target platform through a specific radio virtual machine. Thus, the radio virtual machine includes a back-end compiler that provides a just-in-time or just-of-time (AOT) method for compiling configcodes into executable code.

The radio library consists of functional blocks that represent a computational basis. A radio application can be represented as a collection of such interconnected functional blocks. The functional blocks of the radio library are expressed as a normalized language. The native implementation of the radio library provides executable code of the library's functional blocks for the target platform. The radio library is extensible.

Operational Structure of Integrated Radio Applications

The operational structure of the integrated radio application 125 (450) may be represented in two different cases. The first is where the radio application configcodes are executable code on the target platform (as shown in FIG. 15), and the second is the Intermediate Representation (IR) code that the radio application configcodes are back-end compiled on a given mobile device. Case (example through FIG. 16).

15 is a hierarchical structure diagram illustrating an example of an operation structure of an integrated radio application according to an embodiment of the present invention.

Referring to FIG. 15, a radio library and a user defined function block (UDFB) necessary to perform a given radio application may already be included in executable configcodes of the radio application.

On the other hand, the user function blocks needed to run a given radio application (s) are included in the configcodes of the radio application and must be back-compiled by the radio virtual machine (see FIG. 16). In this case, since the radio library cannot be included in the radio application configcodes, the native implementation of the radio library must be prepared separately within a given mobile device. Typically, the native implementation of a radio library is provided by programmable hardware because the radio library contains standard function blocks (SFBs) that are implemented on programmable hardware.

Radio libraries (native implementations) that can be implemented without using hardware accelerators are needed to speed up standard functional blocks and combine accelerators and program code to create other standard functional blocks.

In either case where the radio application configcodes are executable or intermediate representation code, standard functional blocks are supported by hardware accelerators via the Radio Hardware Abstraction Layer (HAL) 124. It is implemented directly on the corresponding hardware accelerators via the radio HAL, whenever the radio function configcodes are executable or intermediate representation code, whenever standard functional blocks implemented by hardware logic are called by given radio application codes. It must be. As described below, the radio HAL may also include a hardware abstraction for interfaces prepared for user defined function block libraries.

Standard functional blocks are functional blocks commonly used in many radio applications such as the Fast Fourier Transform (FFT) and / or any functional blocks that must be implemented very efficiently using special purpose accelerators in a given radio platform (eg, Turbo coder).

16 is a conceptual diagram illustrating functional block library implementations of a radio platform of a terminal device according to an embodiment of the present invention.

Referring to FIG. 16, the operation structure of the integrated radio application includes the following components.

The integrated radio application 450 assigns the standard function blocks 517-1, 517-3, 517-M and the user-defined function blocks 517-2, 516 to a Radio Application Package (RAP). Corresponding to the contents of the metadata.

The radio library (native implementation) 514 includes Configcodes of standard functional blocks executed on programmable hardware, while standard functional blocks implemented using hardware logic are supported by the radio HAL 431.

Radio virtual machine 515 is a controlled execution environment for software that affects the radio characteristics of a mobile device. Using this, it can be assumed that reconfiguration software, ie radio applications, are loaded into the radio virtual machine.

'User-defined functional block set' 451 is generally provided by a radio application provider and includes all user-defined functional blocks used in a given radio application package. User-defined function blocks are included with the metadata and radio controller code in the radio application package. Since user-defined function blocks are generally modified and / or extended versions of standard function blocks, user-defined function blocks may have dependencies on standard function block libraries.

Radio HAL 431 abstracts radio platform 123. It should be noted that the radio HAL 431 allows standard functional blocks implemented using hardware accelerators to run directly on corresponding hardware accelerators.

The radio platform driver 122 allows the radio OS 121 to recognize the radio platform 123.

The radio platform 123 may generally comprise both programmable hardware and hardware accelerators.

Meanwhile, the aforementioned 'UDFB set' 451 includes all user defined function blocks used by a given radio application. It is important to note that any standard functional block can be modified and / or extensible by replacing it with the appropriate standard functional blocks, ie a modified and / or extended version of the standard functional blocks to be replaced. Thus, some user function blocks can be good candidates for extension of the standard function block, meaning that they can be added later as a standard function block. In this case, after the user function blocks are added as standard function blocks, they will be defined as regular standard function blocks.

In addition, because a 'UDFB set' may be provided by a provider of radio applications (i.e., a 3rd party) on behalf of a radio platform vendor, the radio control framework may provide events and / or events for all user function blocks. In order to be able to perform basic control of commands, a standard set of control interfaces such as 'start', 'stop', 'pause', 'get port' and 'initialize' must be defined for the corresponding user function blocks. Can be. Standard set rules of the control interface for the user function blocks can be given separately. The radio platform 123 shown in FIG. 16 and FIG. 17 below may include programmable hardware and hardware accelerators to implement the respective functional blocks.

17 is a conceptual diagram illustrating functional block library implementations of a radio platform in a terminal device according to an embodiment of the present invention.

In this embodiment, functional block implementations of a radio computer composed of a given radio platform composed of a radio processor and various types of peripheral devices are illustrated.

Referring to FIG. 17, the number of standard functional blocks implemented on a radio processor is M _1, and the number of standard functional blocks SFB implemented on a hardware accelerator is M ₂ . Standard functional blocks implemented using a hardware accelerator (eg, FFT, turbo decoder, MIMO decoder, etc.) may be executed directly on the corresponding hardware accelerator for high performance and low power consumption. These standard functional blocks are supported by a radio hardware abstraction layer (HAL) for execution on the accelerator. This means that each standard functional block running on the accelerator is executed directly via the radio HAL in the corresponding accelerator (s) when called in the radio application. Similarly, each standard functional block executed on a core processor, such as, for example, bit-reverse, multiply and accumulation, is called a radio application (eg, ARM with Neon).

As a result, the executable code required on the radio processor consists of two parts: One part is the executable code of the standard functional blocks executed on the programmable hardware, and the other part is the radio HAL codes for the standard functional blocks executed on the accelerators.

This can be summarized as follows. {C: Execution Codes on Radio Processor Required for Implementation of Standard Function Blocks} = {A: Execution Codes for Standard Function Blocks Running on Programmable Hardware} + {B: For Standard Function Blocks Running on Accelerators Radio HAL codes}. That is, C = A + B and the division of A and B can be determined by each vendor.

This also implies {Standard functional blocks} = {standard functional blocks implemented on programmable hardware} and {standard functional blocks implemented on hardware accelerators} and {standard functional blocks implemented on programmable hardware} and {hardware accelerators The intersection of standard functional blocks implemented on a hardware accelerator is an empty set.

On the other hand, as mentioned above, user-defined functional blocks must be described using a standard interface. As shown in FIG. 17, it should be noted that the standard interface of the user-defined functional block must be associated with one or both of the standard functional blocks implemented on the programmable hardware and the standard functional blocks implemented on the hardware accelerator. do.

The categories of standard interfaces are divided into two groups, one corresponding to standard functional blocks executed on programmable hardware, and one corresponding to standard functional blocks executed on hardware accelerators. Each category has its own advantages and disadvantages. Because. The latter is typically implemented in hardware logic, which is advantageous in terms of power consumption, speedy operation and possibly cost efficiency. On the other hand, the former is advantageous in flexibility since it is generally performed on a microprocessor. In terms of performance, hardware accelerators are expected to be used relatively more extensively at an early stage until programmable devices are competitive over hardware devices. In the long run, as semiconductor technology continues to evolve, programmable hardware-dependent standard functional blocks will become increasingly dominant over peripheral dependent standard functional blocks, and Instruction Set Architecture (ISA) level. It can be implemented by the acceleration function of.

The plurality of standard functional blocks exemplified herein are merely illustrative for the purpose of description as indicating the granularity of data.

Organization of the Radio Application Package

Hereinafter, a configuration of a radio application package (RAP) for distributing a radio application according to the present invention will be described.

Referring to FIG. 18, at least one radio application of the radio application package according to the present embodiment may be composed of functional blocks and a radio controller. That is, the radio application package 510 may include a user defined function block code 511, a radio library, and a radio controller code 512. In addition, the radio application package 510 for distributing the radio application further includes a pipeline configuration meta-data 513 in addition to the user-defined function block code 511 and the radio controller code 512. can do.

The radio controller code 512 determines whether the radio application package is to be included in the form of executable code of which of the radio processor and the application processor according to the above described software architecture environment. That is, if the radio control framework is divided into an application processor execution section and a radio processor execution section, the radio controller code may be composed of code that runs on the application processor. When the radio control framework is executed only on the radio processor, the radio The controller code may consist of code that executes on the radio processor. Meanwhile, as described above, the user-defined function block code 511 may be included in the radio application package as executable code, source code, or intermediate expression code executable in the radio processor in any case. Can be.

A pipeline is a combination of a radio application, user-defined function blocks, and standard function blocks of a radio application for implementing a transmission or reception function of a radio application, and a connection relationship. Can be defined.

In addition, if the standard functional block code is configured in the form of executable code executable in the core of the radio processor, the radio application package 510 may further include a radio library 514 of executable code executable, that is, executable code in which the core of the radio processor is executable. Can be.

The radio application package 510 is generated to include a standard baseband API header 520 by the provider and uploaded to the server 530, from the server 530 to the operating system (OS) of the application processor layer of the user's terminal device. The user-defined function block code 512 and the radio library 514 are downloaded from the application processor to the radio processor by referring to the pipeline configuration metadata 513 to the radio operating system of the radio processor layer. Can be loaded.

The radio application execution method of the above-described embodiments may be implemented to be stored in a computer-readable medium (recording medium) in the form of a program or software implementing the same. The computer readable medium may be embodied in the form of a single or combination of program instructions, data files, data structures, and the like. The programs recorded on the computer readable medium may be those specially designed and configured for the present invention, or may be known and available to those skilled in computer software.

In addition, the computer readable medium may include a hardware device specifically configured to store and execute program instructions, such as a ROM, a RAM, a cache memory, a flash memory, and the like. Program instructions may include high-level language code that can be executed by a computer using an interpreter, as well as machine code such as produced by a compiler. The hardware device may be configured to operate with at least one software module to perform the radio application execution method of the above-described embodiment, and vice versa.

Although described above with reference to a preferred embodiment of the present invention, those skilled in the art will be variously modified and changed within the scope of the invention without departing from the spirit and scope of the invention described in the claims below I can understand that you can.

Claims

In the method of running a modem-independent radio application in the terminal device,

An unified radio application (URA) operating on a radio computer of the terminal device and a radio frequency (RF) transceiver operating on a radio platform on the radio computer communicating with each other using a radio frequency interface (RRFI); And

The RRFI supporting at least one or more of a spectrum control service, a power control service, an antenna management service, a transmit / receive chain control service, and a radio virtual machine protection service;

How to run the radio application.
The method according to claim 1,

The at least one or more services supported by the RRFI are different depending on the reconfiguration class of the terminal device.
The method according to claim 1,

And the RRFI is arranged in parallel or complementary to another radio frequency interface defining a physical interconnection between the baseband and radio frequency integrated circuit of the terminal device.
The method according to claim 1,

The RRFI provides a first interface for configuring the RF transceiver, the first interface being one of the radio application and the RF transceiver corresponding to one of a plurality of radio applications of the integrated radio application according to a radio spectrum environment. At least one of which supports changing control and data information between them.
The method according to claim 4,

The RRFI provides a seventh interface for the integrated representation of control information, and the seventh interface supports the control information via the RF front end connected to the RF transceiver to be expressed in an integrated format for handling the RF front end. How to run a radio application.
The method according to claim 4,

The RRFI provides an eighth interface for an integrated representation of data payload, wherein the eighth interface is an integrated format for data handling of the RF front end, wherein the data payload passing through the RF front end coupled to the RF transceiver How to run a radio application that supports rendering.
The method according to claim 4,

The RRFI provides a ninth interface for selection of an RF protection class, the RF protection class being introduced for a tradeoff between authentication or recertification effort and RF front end flexibility coupled to the RF transceiver, and the RF front end. Flexibility includes band selection, bandwidth selection, out-of-band emission limiting, or a combination thereof.
The method according to claim 1,

The RRFI provides a second interface for expansion of a multi-antenna system, wherein the second interface supports the radio application to select the number of physical input antennas or output antennas according to a wireless environment.
The method according to claim 1,

The RRFI provides a third interface for multi-frequency band capability, the third interface supporting a plurality of radio applications using separate frequency bands.
The method according to claim 1,

The RRFI provides a fourth interface for reconfiguration of the RF transceiver, the fourth interface supporting the RF transceiver to manage one or more output signals or received signals from or to one or more radio applications; How to run the radio application.
The method according to claim 1,

The RRFI provides a fifth interface for interoperation of the radio resources, and the fifth interface supports a plurality of radio applications to share radio resources.
The method according to claim 1,

The RRFI provides a sixth interface for testing of wireless equipment, the sixth interface supports a test mode having test capability of the RF path without radiating radio waves, and the test mode is a transmission coupled to the RF transceiver. And a loopback mode in which the chain is coupled to the receive chain.
The method according to claim 1,

The RRFI is based on an extension of the classes of the radio computer, the radio computer classes being measured by radio control (RCMeasurements), radio controller configuration (RCConfiguration) and its subclasses, channels and their subclasses and radio control capabilities ( How to run a radio application, including RCCapabilities).
The method according to claim 13,

And the RRFI connects the radio virtual machine software component and baseband implementation integrated circuit of the baseband processing device of the terminal device with the chain of the RF transceiver or RF frontend.
A terminal device for executing a radio application independent of a modem,

An unified radio application (URA) operating on a radio computer of the terminal device;

A radio frequency (RF) transceiver operating in a radio platform on the radio computer;

A radio frequency interface (RRFI) connecting between the URA and the RF transceiver and supporting at least one of spectrum control service, power control service, antenna management service, transmit / receive chain control service, and radio virtual machine protection service; Including, the terminal device.
The method according to claim 15,

The RRFI supports the at least one or more different services according to the reconfiguration class of the terminal device.
The method according to claim 15,

The RRFI is arranged in parallel or complementary with another radio frequency interface defining a physical interconnection between the baseband and radio frequency integrated circuit of the terminal device.
The method according to claim 17,

The terminal device comprises a radio virtual machine software component that selects radio frequency and radio virtual machine protection classes and the baseband processing device including an integrated circuit of a baseband implementation, and an RF coupled with the baseband processing device via the digital interface. And a front end chain or an RF transceiver chain, wherein the radio virtual machine software component and the baseband implementation integrated circuit and the front end chain or the RF transceiver chain communicate with each other using the RRFI.
The method according to claim 15,

The spectrum control service includes operations of center frequency setting, bandwidth setting and sampling rate setting.
The method according to claim 15,

The RRFI includes a first interface for the spectrum control service, wherein the first interface transmits a message requesting a center frequency setting, a bandwidth setting, or a sampling rate setting from the URA to the RF transceiver. Confirm the center frequency setting, confirm the bandwidth setting, confirm the sampling rate setting, answer the failure of the center frequency setting, or answer the failure of the bandwidth setting from the RF transceiver to the URA; And transmitting a message for responding to the failure of the sampling rate setting.