KR20170040972A - Method and terminal device for running radio applications - Google Patents

Abstract

Disclosed are a method and terminal device for executing a radio application. The method for executing a radio application, in which a terminal device executes a radio application independent from a modem, comprises the steps of: performing communication between a unified radio application (URA) configured to operate on a radio computer of a terminal device, and a radio frequency (RF) transceiver configured to operate via a radio platform on the radio computer, by using a reconfigurable radio frequency interface (RRFI); and supporting, by the RRFI, at least one of spectrum control service, power control service, antenna management service, transmission and reception chain control service, and radio virtual machine protection service.

Description

[0001] METHOD AND TERMINAL DEVICE FOR RUNNING RADIO APPLICATIONS [0002]

The present invention may be implemented in software defined radio (SDR), digital wireless communications, a radio processor (RP), an application processor (AP), or a multi-radio application To a method and a terminal device for a mobile device to execute a radio application.

More particularly, the present invention relates to a reconfigurable radio frequency interface (RRFI) structure for controlling a radio application (RA), and more particularly, to a structure of a reconfigurable radio frequency interface (RRFI) And a reconfigurable RF interface for controlling the execution of the reconfigurable RF interface.

As communication technology develops, many new kinds of radio communication technologies are being used depending on user's preference or purpose. Most of the wireless communication technologies such as Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-advanced), Wideband Code Division Multiple Access (WCDMA), Mobile WiMAX, GSM (Global System for Mobile Communications) And the base station executes on the terminal while interacting.

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

However, it is practically impossible to produce a radio application that can be operated on all terminals, since optimization must be separately performed according to the hardware of various modems currently on the market. In addition, there is a problem that existing technology requires a lot of manpower and cost to produce a multi-radio application.

In order to solve this problem, there is an attempt to create a hardware independent multi-radio application, but in order to control it, it is necessary to use a unified command instead of a unique command for each manufacturer.

That is, there is a need for a technology that converts HF (High Frequency) to HF into software in wireless base stations and terminals. Software Defined Radio (SDR) is a wireless communication system that can provide services economically to a single terminal in a multi-mode, multi-band, It is an object of the present invention to provide a wireless device and a service by operation of software with a communication technology.

When a software defined radio module is mounted on a portable terminal such as a mobile phone, a personal digital assistant (PDA), or a notebook computer, it is possible to support different frequency bands and two or more systems simultaneously in one terminal. SDR is a technology capable of providing various communication methods for various wireless networks, various wireless communication methods, frequency bands for different countries, and high-speed data communication in 4th generation communication pursuing All-IP based wireless multimedia communication.

There is a de facto standard technology called Software Communication Architecture (SCA) in relation to software defined radio technology. It is a collection of protocols related to the framework, middleware, and real-time operating system required for software defined radio and ensures interface compatibility between software defined radio systems. The core of SCA is the core framework, which is a framework protocol that allows component parts of a radio application to be componentized and reused and combined to create new radio applications.

In case of SCA, it is possible to reconfigure only the blocks installed in the terminal, but it is not possible to install user defined blocks for use in specific radio applications in SCA compatible terminals having different hardware configurations. Therefore, it is impossible to use a single executable on all SCA compatible terminals.

This means that optimized executables must be individually created and distributed according to the specifications of the hardware installed on all SCA compliant terminals. This causes a great deal of time and money, making commercial use of the radio application very difficult. In addition, the SCA compatible terminal does not provide a baseband API (application programming interface) for implementing a radio application, making it difficult to utilize the optional hardware acceleration function.

It is an object of the present invention to provide a terminal device that executes a hardware independent radio application.

It is another object of the present invention to provide a method capable of hierarchically separating various components operating in a processor in a terminal device and allowing each component to interact with each other, thereby executing a radio application in a hardware independent manner.

According to an aspect of the present invention, there is provided a terminal device including an application processor and a radio computer, the terminal device executing a radio application (RA), wherein the integrated radio application and the RF transceiver And a Reconfigurable Radio Frequency Interface (RRFI) for interacting with each other.

According to another aspect of the present invention, there is provided a method of executing a modem-independent radio application in a terminal device using a baseband application programming interface, the method comprising: receiving a unified radio application (URA) Comprising the steps of: a radio frequency (RF) transceiver operating on a radio platform on a radio computer communicating with each other using a reconfigurable radio frequency interface (RRFI); and transmitting the RRFI to 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, is provided.

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 RRFI may be arranged in parallel or complementary to another radio frequency (RF) interface that defines 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 the configuration of the RF transceiver. The first interface may support at least one of the radio application and the RF transceiver corresponding to one of the plurality of radio applications of the integrated radio application to change control and data information therebetween according to the radio spectrum environment.

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

Here, the RRFI may provide an eighth interface for an 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 represented 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 for tradeoffs between authentication or re-authentication efforts and RF front-end flexibility connected to RF transceivers, and RF front-end flexibility includes band selection, bandwidth selection, out-of-band emission limiting, can do.

Here, the RRFI provides a second interface for extension of the multi-antenna system, and the second interface can support the radio application to select the physical input or output antennas according to the radio environment.

Here, RRFI provides a third interface for multiple frequency band capabilities, and the third interface can support multiple radio applications using separate frequency bands.

Here, the RRFI provides a fourth interface for reconfiguring the RF transceiver, and the fourth interface may support an RF transceiver to manage one or more output signals or received signals from one or more radio applications or to a radio application.

Here, the RRFI provides a fifth interface for interworking of radio resources, and the fifth interface can support a plurality of radio applications to share radio resources.

Here, the RRFI provides a sixth interface for testing of wireless devices, the sixth interface supports a test mode with test capability of the RF path without radio wave radiation, and the test mode includes a transmit chain that is connected to the RF transceiver And a loopback mode coupled to the receive chain.

Here, the RRFI is based on an extension of the classes of the radio computer, and the radio computer classes include RCMeasurements, RCConfiguration and its subclasses, channels and their subclasses, and radio control capabilities RCCapabilities).

Here, the RRFI may be connected to each of the RF virtual machine software component and the baseband implementation integrated circuit of the baseband processing device of the terminal device and a 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 for executing a modem-independent radio application having an application programming interface, comprising: a unified radio application (URA) operating on a radio computer of a terminal device; A radio frequency (RF) transceiver operating on a radio platform on a radio computer; A reconfigurable radio frequency interface that interconnects the URA and RF transceiver and supports at least one 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, RRFI). ≪ / RTI >

Here, the RRFI can support at least one or more services different depending on the reconfiguration class of the terminal apparatus.

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

Herein, the terminal device includes a baseband processing device including a radio virtual machine software component and a baseband implementation integrated circuit for selecting radio frequency and radio virtual machine protection classes, and a baseband processing device including a baseband processing device and an RF A front end chain or an RF transceiver chain. Each of the radio virtual machine firmware components and the baseband implementation integrated circuit and the RF front end chain or the RF transceiver chain can communicate with each other using RRFI.

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

Here, the RRFI may include a first interface for the spectrum control service. The first interface requests a center frequency setting from the URA to the RF transceiver, requests a bandwidth setting, transmits a message requesting a sampling rate setting, confirms a center frequency setting from the RF transceiver to the URA, confirms a bandwidth setting, or sets a sampling rate Or to respond to the failure of the center frequency setting, to respond to the failure of the bandwidth setting, or to reply to the failure of the sampling rate setting.

By using the terminal device and the method for executing the radio application according to the present invention as described above, various radio applications independent of the hardware platform of the terminal device can be installed and used in the terminal device.

In addition, in the aspect of a mobile communication service provider, it is possible to switch terminals having various radio platforms used by their network subscribers to a desired communication network standard as needed, thereby enabling a flexible network operation.

In addition, when a user needs to switch to a new communication network, it is not necessary to purchase a new terminal, and a new communication network can be used only by downloading a radio application package and installing a radio application in his / her terminal.

1 is an exemplary diagram for explaining a case of downloading a radio application package distributed in an online application 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 for explaining four interfaces related to a terminal device in a use environment of a reconfigurable terminal device according to an embodiment of the present invention.
4 is a conceptual diagram for explaining how 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.
5 is a UML diagram of the elements of RRFI in the terminal device of FIG.
6 is a block diagram schematically illustrating an architecture of a terminal device according to the present embodiment.
FIG. 7 illustrates a Unified Modeling Language (UML) class diagram of a radio computer related to a reconfigurable radio frequency interface (RRFI) in a radio application execution method of a terminal apparatus according to another embodiment of the present invention.
8 is a block diagram illustrating an entire architecture of reference points for a terminal according to an embodiment of the present invention.
FIG. 9 is an exemplary diagram illustrating an example of reference points for installing / uninstalling and instance creation / deletion of a radio application in the terminal device of FIG. 8. FIG.
10 is an exemplary diagram illustrating an example of reference points for obtaining a list of radio applications in the terminal device of FIG.
11 is an exemplary diagram illustrating an example of reference points for activating / deactivating a radio application in the terminal device of FIG.
12 is an exemplary diagram illustrating an example of reference points for delivery of context information in the terminal device of FIG.
13 is an exemplary diagram illustrating an example of reference points for data flow generation and user data transmission / reception in the terminal device of FIG.
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 diagram illustrating an example of the operation structure of an integrated radio application in a terminal device according to an embodiment of the present invention.
16 is a hierarchical diagram illustrating another example of the 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 for explaining a configuration example of a radio application package that can be employed in a terminal device according to an embodiment of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. Like reference numerals are used for like elements in describing each drawing.

The terms first, second, A, B, etc. may be used to describe various elements, but the elements 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 a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises" or "having" and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component or a combination thereof described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations 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 to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

Brief definitions of terms used throughout to describe the present invention are summarized. For definitions of terms other than the following terms, definitions are given in the relevant part of this specification.

Radio Application (RA): An application for providing a specific hardware configuration of a terminal device and an independent radio communication environment for a user application. The radio application may be configured to operate on a radio processor, or on a dual processor configured with 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 custom function blocks.

Radio Application Package (RAP): A type of distribution of radio applications, including pipeline configuration metadata along with radio controllers, function blocks, which are components of a radio application. In addition, the radio application package may additionally include a radio library.

Standard Function Block (SBF): A standard function block is a standard functional block that standardizes the function of each block and the name of a function for executing the corresponding block. The standard function block will be a collection of standard function blocks implemented by the hardware manufacturer and may be provided with the driver if the radio platform chip vendor produces a standard function block. The standard function block may be implemented using a dedicated hardware accelerator or as executable code running on the core of the radio processor. When implemented as executable code that runs on the core of a radio processor, it can be referred to as a radio library. Standard function blocks are standardized with the name and function of each function and can be defined by a standard radio library header file.

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

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

Radio HAL (Hardware Abstract Layer): It is a layer that abstracts many types of HW in terms of OS. The standardized abstraction accelerator interface is hardware independent, but the HAL makes the OS accessible to all hardware. The HAL is similar to the driver, but unlike the driver that changes as hardware changes, the HAL is included in the OS.

Radio Platform Driver: Software that OS needs to recognize hardware. It is a hardware independent OS command, which is software for matching hardware instruction systems to each other and can serve as a general hardware driver.

Radio Platform: may be part of mobile device hardware for RF functions such as fixed and / or programmable hardware accelerators, RF transceivers, antennas. That is, the radio platform may be part of the hardware capable of generating or receiving RF signals. In essence, the radio platform may be heterogeneous hardware, including, for example, fixed accelerators such as application specific integrated circuits (ASICs) or other processing elements such as reconfigurable accelerators such as FPGAs .

Radio Computer: A collection of Radio Platform (RP) and Radio Platforms within a reconfigurable Mobile Device (MD). In a mobile device, individual radio applications may be designed as a software component running on a radio processor that may be viewed as a more general purpose computing element.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In order to facilitate the understanding of the present invention, the same reference numerals are used for the same constituent elements in the drawings and redundant explanations for the same constituent elements are omitted.

1 is a diagram illustrating an example of downloading a radio application package distributed in an online application store in a terminal device according to an embodiment of the present invention.

Referring to FIG. 1, a terminal device according to the present embodiment can download and install a radio application in various wireless network environments. That is, the user accesses the online application 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 application store, You can download the included radio application package.

Various wireless systems may include Long Term Evolution (LTE), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile Communications (GSM), Radio Frequency Identification have. The user can download and install a plurality of radio applications in his / her terminal, and freely execute necessary radio applications according to the situation.

radio Application  Configuration and software architecture

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

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

Figure 2 illustrates a software architecture environment in which a Radio Control Framework (RCF) described below operates on two processors separated by an application processor execution portion and a radio processor execution portion. Of course, the radio control framework can be implemented to run on a radio processor or a radio operating system (OS).

On the application processor, a non-real time operating system (OS) such as Google's Android OS and Apple's iOS is operated, and on the radio processor, A real-time operating system operating in a radio processor layer is called a 'real-time operating system' (hereinafter referred to as a 'real-time operating system' Operating system (Radio OS) '.

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

application  Processor layer

The application processor layer may include components such as a driver, an operating system (OS), and a communication service layer, as shown in FIG.

The driver runs hardware devices on a given operating system. The hardware devices may include a camera, a speaker, and the like.

The operating system may include a non-real time operating system running on a conventional mobile device such as Android, iOS. When the radio control framework is configured to operate on an application processor and a radio processor, there may be an application processor layer implementation 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 a service related to administration, related to installation / uninstallation of a radio application, creation / deletion of an instance, installation of a radio application on the status of installation, instance, activity, etc. .

The second service is a service related to connection control related to the execution / non-execution of a radio application, a data flow generation, a network allocation creation, and a list acquisition of a radio application for each installation, instance, activity,

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

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 monitor, and the like. The networking stack may include a protocol stack operating in the communication service layer.

On the other hand, the communication service layer may include only some of the above-described components, and may include additional components other than the above-described components. In addition, the communication service layer may include components with integrated functions of at least two or more of the above-described components. In addition, the above-described components are merely examples of components that the communication service layer must provide in order to support the services that the communication service layer should perform. That is, the communication service layer is defined by the role performed by the communication service layer, and the configuration of the communication service layer is not limited by the example of 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 to be distributed, installed and executed in the terminal device according to the present embodiment include application processor layer execution portion and radio processor layer execution portion . ≪ / RTI > The Radio Controller (RC), which is the execution part of the application processor layer of the radio application, sends context information to the monitor of the communication service layer or exchanges 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.

A radio operating system (OS) is a real-time operating system. When the radio control framework is configured to operate 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, such as a generic hardware driver.

If the radio control framework is configured to operate only on the radio processor (see FIG. 3), the reconfigurable radio applications to be distributed, installed and executed in the terminal device according to the present embodiment can operate in the radio processor layer.

The 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 constitute a radio computer with a radio platform or radio platform hardware. Here, the radio platform hardware can generally be comprised of programmable hardware and baseband accelerator (s) of the radio processor. Baseband accelerators prepared for the standard function 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) can be placed between the above-mentioned communication service layer and a control radio control framework, and an integrated radio application interface (URAI) can be provided between the radio control framework and the integrated radio application. Can be disposed. Also, a reconfigurable radio frequency interface (RRFI) may be placed between the integrated radio application and the RF transceiver.

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

The radio library may be included and distributed in the form of executable code in a radio application package when the standard function block is distributed in the form of executable code. The radio application package is downloaded to the OS of the application processor layer, The radio library can be loaded into the radio OS layer of the radio processor layer by loading the radio processor from the application processor with reference to the pipeline configuration metadata.

Radio control Framework

The Radio Control Framework (RCF) is a component that provides the operating environment for a radio application.

If the radio control framework is configured to run on an application processor and a radio processor, the radio control framework can be divided into two groups. That is, one group operates on an application processor and the other group operates on a radio processor. Which component of the radio control framework is to be operated in real time (on the radio processor) and which component is to be operated in non-real time (on the application processor) can be determined differently for each vendor.

The Radio Control Framework (RCF) can be configured to manage the radio application (s), basically 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 be comprised of components that incorporate at least two or more of the functions of the following components. The functions and roles of the radio control framework are defined by the functions performed by the following components, 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 following components.

Configuration Manager (CM): Install / uninstall radio applications, create / delete instances for multi-radio terminal devices, and manage access to radio parameters of 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): transmission and reception of user data packet and flow control.

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

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

Software architecture of reconfigurable RF interface

3 is a conceptual diagram for explaining four interfaces related to a terminal device in a use environment of 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 may be capable of simultaneously executing multiple radios and may be configured with 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 the radio reconfiguration of the mobile device.

In order to implement multiple / multiple integrated radio applications, a reconfigurable mobile device (hereinafter briefly referred to as a mobile device) includes a Communication Services Layer (CSL), a Radio Control Framework (RCF) (Radio Platform) and four sets of interfaces for interconnecting them.

The four interfaces associated with 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 ), Reconfigurable Radio Frequency Interface (RRFI), which is the interface between the Unified Radio Application (URA) and the RF Transceiver (Radio Frequency Transceiver), between each component of the Integrated Radio Application and Radio Control Framework Interface, a Unified Radio Application Interface (URAI), and a radio programming interface (RPI), an interface related to the independent, uniform production of radio applications.

A reconfigurable RF interface (RRFI) is an interface defined between an integrated radio application and an RF transceiver. In other words, it means the interface between URA and radio spectrum.

4 is a conceptual diagram for explaining how an integrated radio application and an RF transceiver interact with each other using RRFI in a reconfigurable terminal device according to an embodiment of the present invention. 5 is a UML diagram of the elements of RRFI in the terminal device of FIG.

As shown in FIGS. 4 and 5, the RRFI can support at least one of the following five types of services. The five services include 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 of the RF transceiver system. Different radio applications may have their own spectral setting values. That is, the spectrum control service can be used to set spectrum related parameters such as carrier frequency, bandwidth, sampling frequency, and the like.

For spectrum control services, RRFI can provide a first interface. In this case, the first interface requests a center frequency setting from the URA to the RF transceiver, requests a bandwidth setting, transmits a message requesting a sampling rate setting, confirms a center frequency setting from the RF transceiver to the URA, confirms a bandwidth setting You can acknowledge the sampling rate setting, respond to the failure of the center frequency setting, respond to the failure of the bandwidth setting, or deliver a message to respond to the failure of the sampling rate setting.

The power control service is used for power-related settings of the RF transceiver system. For example, the power control service includes a maximum Tx power level, a Tx power level per antenna, a receive gain / sensitivity level, a transmit / receive gain Tx / Rx gain, Rx gain, and the like. The power control service is preferably controlled by specific power schemes depending on the communication environment around the reconfigurable mobile device. A particular output schema may include day, night, event, power saving, and the like.

For power control services, RRFI can provide a second interface. In this case, the second interface may request the maximum power level setting of the transmit chain from the URA to the RF transceiver, request the transmit power setting per transmit antenna, request the receive gain setting of the receive chain, or request transmit power level measurement of the active radio application And confirms the maximum power level setting of the transmit chain from the RF transceiver to the URA, confirms the transmit power setting per transmit antenna, confirms the receive gain setting of the receive chain, or fails to set the maximum power level of the transmit chain Or may respond to a failure of the transmit power setting per transmit antenna, or may transmit a message that responds to the failure of the receive gain setting of the receive chain. The second interface may also convey information related to the measurement of the transmit power level of the active radio application to the URA in the RF transceiver.

Antenna management services may be used to determine the antenna configuration, such as antenna port selection and RF radiation type of the RF transceiver system. For example, in an antenna management service, an antenna radiation pattern, an antenna gain, an antenna direction, a sector configuration (e.g., 3x1, 1x1, etc.) Some factors such as physical antenna type (e.g., multi-pad, MIMO, SIMO, MISO, SISO, etc.), polarization, frequency range, etc., can be considered.

For antenna management services, RRFI may provide a third interface. In this case, the third interface may request a transmit antenna port selection from the URA to the RF transceiver, or may transmit a message requesting selection of a receive antenna port, and the RF transceiver may confirm the transmit antenna port selection to the URA or confirm the receive antenna port selection Or transmit a message that responds to the failure of the transmit antenna port selection or that the receive antenna port selection fails.

The transmit and receive chain control services can be used to provide parameters related to the real-time control of the RF transceiver chain. For example, the parameters of the transmit / receive chain control service can be controlled using transmit / receive chain control services, where the transmit / receive chain control services are configured to transmit start / / stop time, receive start / stop time up, spectrum- and / or power-related values, Update of Tx / Rx chain parameters), and the like. According to the transmission / reception chain control service, the URA-generated baseband signal is transmitted to the RF transceiver, and the spectrum and / or power setting values during real communication can be controlled in real time have.

For transmit / receive chain control services, RRFI can provide a fourth interface. In this case, the fourth interface requests the setting of the transmission start time from the URA to the RF transceiver, requests the transmission end time setting, requests the reception start time setting, requests the reception end time setting, or transmits a message requesting update of the transmission / reception chain parameter And the RF transceiver can check the transmission start time setting, check the transmission end time setting, check the reception start time setting, check the reception end time setting, check transmission / reception chain parameter update, Reply a failure of setting the transmission end time, reply a failure of the reception start time setting, reply a failure of the reception end time setting, or reply a failure of the transmission / reception chain parameter update.

The RVM protection service can be used to provide parameters related to the selection of the RVM Protection class. For example, the parameters controlled using the RVM protection service may include an RF front end indication of the input data signal change as well as the selection and / or request of the RF protection class. The RVM protection service will be described in more detail as follows.

RVM Protection  Service (radio virtual machine protection services)

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

The selection of RF protection class is as follows. That is, in the context of software reconfiguration, the RF front end generally allows selection of RF protection classes. A suitable protection class may generally comprise a software component and may influence the 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 message (ACK) issued by the RF front end in the case of a successful operation and to the issuance of a not acknowledgment (NACK) message in case of a failure. The RF front end may then select a higher level protection class, including the addition of the required protection function, even if the specific support required for the protection class is not provided. This may lead to the issuance of an acknowledgment with modification (ACKM) message. As far as possible, details of the selection of modified protection classes can be provided on request. If a request for a protection class is specifically indicated as not selecting a higher class, such as a more restrictive protection mechanism that prevents software components from functioning properly, if the requested specific protection class is not available, A lower class can be selected. On the other hand, this may require a more detailed recertification (conformance declaration) process, since lower protection classes may lead to less protected frontends, which may pose a higher risk to other users.

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

Describing the request for change of RF protection classes, RF protection can be changed according to current active radio access technology. For example, if hare-wired WiFi is used and RF protection classes are not required or they are inactive. 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 reauthentication (declaration of conformity) of the mobile device in question. Modification of the protection class may be performed based on a specific external trigger for the RF front end. For example, the RF front end may be programmed to be (temporarily) reconfigured temporarily or in accordance with a request that depends on the input waveform or radio access technology (RAT) data such that the RF protection class is changed to active or inactive.

Describing an RF front-end indication of modulation of the input data signal, the RF front-end protection mechanism selected as one of the higher processors reduces the output power level, , It may provide the corresponding information on the output of the RF front end as a message. This can usually be handled by the baseband and / or application processor.

If the RF front-end emergency switch off detects a large-scale violation of the emission limit, such as a large out-of-band / spurious emission, the RF front-end may stop the transmission You can decide. On the other hand, other transmissions or simultaneous transmissions can still continue if they meet the limit.

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

Class definitions for interface

Each interface class associated with RRFI can be defined using the UML diagram of FIG. 5, which illustrates the interface classes, and the template shown in Tables 1 to 3 below. Tables 1 to 3 show operations related to the interface classes for the three services among the interfaces for the five services described above.

At least one or more services 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 according to its MDRC as shown in Table 4 below. If the reconfigurable mobile device supports multiple MDRCs, then the reconfigurable mobile device may support all services related to MDRC.

Here, the URA may be defined as a 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.

Transceiver systems, including transceiver chains and antennas, can also be defined as part of a radio platform in a radio computer that converts baseband signals to radio signals for transmission and radio signals to baseband signals for reception. have.

A class can also be a template, or 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 is, for example, one of the concepts defining object-oriented programming, in which all or part of a class can have a subclass inherited from the class property, in which case the class can be a superclass for each subclass. A subclass can define its own methods and variables, and the structure between subclasses and classes can be called a class hierarchy. A method may refer to a portion of a schedule code that performs a particular operation in the software together with a function, subroutine, routine, or procedure.

MDRC-1, MDRC-1, MDRC-2, MDRC-4, and MDRC-5 are the classes of mobile devices that can not be reconfigured, MDRC-3 and MDRC-6 represent classes of mobile devices with static resource requirements; MDRC-4 and MDRC-7 represent classes of mobile devices with dynamic resource requirements; . MDRC-2, MDRC-3, and MDRC-4 are the classes that can download the platform-specific executable code and implement RRFI. MDRC-5, MDRC-6 and MDRC- Are the classes that can implement.

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

Describing components of a radio computer in more detail, an integrated radio application (URA) may be defined as part of a radio processor within a radio computer.

An RF transceiver may include at least one RF transceiver chain and at least one or more antennas. The RF transceiver may be part of a radio platform within a radio computer. The radio platform may convert a baseband signal to a radio signal in a transmit mode and a radio signal to a baseband signal in a receive mode.

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

In addition, existing interface standards may be referred to as other radio frequency interfaces (RF Interfaces). In particular, other radio frequency interfaces (RF Interfaces), including DigRF, etc., operate on the radio platform in conjunction with the RF transceiver and can deliver signals or service between the RF transceiver and the integrated radio application (URA).

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

The system requirements include a first system requirement (R-FUNC-RFT-01) for RF configuration, a second system requirement (R-FUNC-RFT-01) for extendibility for multiple- FUNC-RFT-03 on the capacity of multiple frequency bands (R-FUNC-RFT-03), the fourth system requirement on the reconfigurability of RF transceivers (R-FUNC-RFT-05) on interoperability of radio resources, R-FUNC-RFT-05 on testability of radio equipment FUNC-RFT-06), the seventh system requirement (R-FUNC-RFT-07) on the unified representation of control information, and the union representation of data payload (R-FUNC-RFT-08), and selection of RF protection class (R-FUNC-RFT-09) relating to < RTI ID = 0.0 >

The mapping of URA, RF transceiver and RRFI to system requirements, which are entities, components or units of the above-described radiocomputers, is illustrated in Table 5 below. Table 5 also provides brief comments on the functionality of the mapped system requirements.

Interface definition

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

6, a terminal device according to the present embodiment includes a radio virtual machine (RVM) for baseband processing, a base-band integrated circuit (Hard-wired) type of application specific integrated circuit (ASIC) And an RF front end or RF transceiver chain (RF Front-End / RF transceiver chain). The radio virtual machine software component (RVM software component) can select the RF and RVM protection classes. The base-band processing device may be connected to an application processor or a MAC (Layer 2) and a higher layer processing device.

In addition, the terminal device may include an analogue digital converter and a digital-to-analog converter between the RF front end or the RF transceiver chain and the baseband processing device. Here, analog digital converters and digital analog converters can be implemented by existing interface standards such as DigRF, which is not specified in RRFI.

The RF front end or RF transceiver chain and the RVM software component or baseband implementation integrated circuit may be connected by the reconfigurable radio frequency interface (RRFI) of this embodiment.

Information Model for Radio Computer

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

The radio computer classes related to the RRFI 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 the reconfigurable mobile device. For example, a RadioComputer class may include computational / spectral resource usage, a collection of context information, channel measurement results, and the like. The RadioComputer class can be associated with a user class or the like via the IRRFI class.

The RCCapabilities class includes information about radio computer (RC) capabilities including hardware, software, transmission and measurement capabilities such as supported wireless interfaces, maximum transmission power, and the like. Each instance of the radio computer 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 radio computer 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 the air interface used. Each instance of the Channel class may contain only one instance of the ChannelProfile class as a member.

The ChannelMeasurements class may include current measurements related to frequency channels (instantaneous measurement data and performance statistics derived from this data), such as interference and load measurements. Each instance of the Channel class may contain 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 can contain 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 wireless terminal and the 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 can 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 serving cell ID, a channel used, and the like. Each instance of the Link class can contain only one instance of the LinkProfile class as a member.

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

The RFConfiguration class contains information about the configuration of the 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 the RFConfiguration class may have zero, one, or several instances of the transmit path class or chain class as its members.

The receive path (RxPath) class describes one receive path. Each instance of the RF Configuration class can have only one instance of the receive path class or chain class as a member.

The Antenna class includes information about 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 AntennaProfile class and an AntennaMeasurments class as subclasses.

The AntennaProfile class includes general information of the antenna, such as an antenna identifier (ID). Each instance of the Antenna class may contain only one instance of the AntennaProfile class as a member.

The AntennaMeasurments class may include current measurements related to the antenna, such as gain measurements, 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, such as instantaneous measurement data and performance statistics derived therefrom, such as battery capacity or terminal location measurements. Each instance of the radio computer class can have only one instance of the RF measurement class (RCMeasurements) as a member.

The RCProfile class may include general information about a radio computer, for example, a terminal identification (terminal ID). Each instance of the RadioComputer class can have only one instance of the RC profile class as a member.

Class Definitions for Information Model

Each class of the above-described radio computer can be defined using a UML (Unified Modeling Language) diagram of FIG. 7 describing the relationship between all the classes of the radio computer and a predetermined template such as Tables 6 to 22 below. have. Tables 6 through 22 also illustrate related operations of radio computer classes.

Software architecture reference  Reference points

The following description are examples of interfacing procedures and interfaces between a radio control framework and a radio application to implement installation / uninstallation of integrated radio applications, creation and deletion of instances, and operation.

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

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 includes (CM) 731, a radio connection manager (RCM) 732, a flow controller (FC) 733, a multi-radio controller (MRC) 734 and a resource manager Includes an administrator (Admin) 741, a mobility policy manager (MPM) 742, a networking stack (N / W stack) 743 and a monitor 744.

A solid line (CF1, CF2, CF3, CF4, CF5, CTRL1, CTRL2, DCTRL1, DCTRL2, DCTRL3, CII) between two blocks is a reference point defined between two blocks, Reference point " On the other hand, a dotted line between two blocks means a reference point performed by an interaction via a radio operating system (Radio OS) based on a command issued by a corresponding block. As will be described later, the blocks of the RCF, e.g., the configuration manager CM, the radio connection manager RCM, the multi-radio controller MRC, and the resource manager RM, .

The definition of each reference point consists of three types of interfaces: Multiple Radio Interfaces (MURI), which are the interfaces between the components of the radio control framework and the components of the communication service layer, Radio Application) and Unified Radio Applications Interfaces (URAI), which are the interfaces between the components of the radio control framework, and Reconfigurable Radio Frequency Interfaces (RRFI), which are interfaces between integrated radio applications and RF transceivers. In addition to the interfaces belonging to MURI, URAI and RRFI, the interfaces between the RCF's components are also defined as reference points. In this embodiment, the reference points can be classified according to the procedure of each function such that the classification for each reference point corresponds to an operation procedure described below.

Reference Point 1: Radio Application install (install) / Unins Uninstall and Instance interfaces for creating / deleting instances

FIG. 9 is an exemplary diagram illustrating an example of reference points for installing / uninstalling and instance creation / deletion of a radio application in the terminal device of FIG. 8. FIG.

Referring to FIG. 9, CF1a indicates that the administrator 741 instructs the configuration manager 731 to install or uninstall the radio application, or when the manager 741 requests the CM 731 It is the interface between the manager and the configuration manager to receive a response.

CF2a may be used by the mobility policy manager 742 to request the configuration manager 731 to create or delete an instance of the radio application or to allow the mobility policy manager 742 to receive a response to the request from the configuration manager 731, It is the interface between the policy manager and the configuration manager.

The CF4 requests the setting manager 731 to transmit parameters related to the radio resources to the multiradio controller 734 during the procedure of generating the radio application instance or when the setting manager 731 requests the radio resource Lt; / RTI > is the interface between the configuration manager and the multi-radio controller for receiving a response to a request for parameters associated with the configuration manager.

The CF 5 requests the configuration manager 731 to transmit parameters related to computational resources to the resource manager 735 during the procedure of generating the radio application instance or when the setting manager 731 requests the resource manager , And 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 Applications  List Checking  Interfaces for

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

10, the CF1b requests the manager 741 to transmit the radio application list to the setting manager 731 or when the manager 741 receives a response to the request from the setting manager 731, that is, It is the interface between the manager and the configuration manager to receive a response to the request.

The CF2b requests the mobility policy manager 742 to transmit the radio application list to the setting manager 731 or when the mobility policy manager 742 receives a response to the request from the setting manager 731, Lt; RTI ID = 0.0 > a < / RTI > mobility policy manager and a configuration manager.

Reference Point 3: Radio Application  Interfaces for enabling / disabling

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

Referring to FIG. 11, CTRL1a indicates that the mobility policy manager 742 requests the radio connection manager 732 to activate or deactivate the radio application, or when the mobility policy manager 742 requests the radio connection manager 732 To receive a response to the request from the radio link manager.

Reference Point 4: Interfaces for communicating context information

12 is an exemplary diagram illustrating an example of reference points for delivery of context information in the terminal device of FIG.

Referring to FIG. 12, the CII requests a monitor 744 to send status information to a radio controller part 721 of a radio application of the radio application, or when the monitor 744 requests the request To the radio controller of the radio application.

The context information is generated in the corresponding functional blocks of the radio applications and transmitted to the radio controller of the radio application. Interfaces must exist between each of the radio controllers and corresponding functional blocks within the radio applications. This implies that in particular the BBI (Baseband Interface) must be defined for communicating context information between the radio controller and the respective functional blocks.

Reference Point 5: Interfaces for Data Flow Generation and Transmission and Reception of User Data

13 is an exemplary diagram illustrating an example of reference points for data flow generation and user data transmission / reception in the terminal device of FIG.

Referring to FIG. 13, CTRL1b indicates that the mobility policy manager 742 requests the radio connection manager 732 to establish a data flow or network association with peer equipment, 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 is used by the radio connection manager 732 to request the flow controller 733 to form a data flow or the radio connection manager 732 to send a radio connection It is the interface between the manager 732 and the flow controller.

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

DCTRL2 includes a flow controller for requesting the flow controller 733 to communicate user data to the radio application 720 or to transmit radio application 720 information of the sending user data such as throughput, It is the interface between radio applications. DCTRL2 is also used by the 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 transfer the receive user data from the radio application 720 to the flow controller 733. [

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

Radio processor layer software Architecture

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

Once the radio application package is downloaded, the custom function block code and the radio library, which should be operated at the radio processor layer, are installed to be accessible at the radio processor layer.

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

In the following description, the actual radio platform is defined as a target radio platform, and the concept of a shadow radio platform is defined as a virtual medium having hardware abstraction for the target radio platform. The shadow radio platform may be a radio platform that a developer of a radio application has simulated as the 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. If the shadow radio platform is different from the target radio platform, the shadow radio platform can be understood as a hardware-independent virtual device, corresponding to the actual target radio platform, so the shadow radio platform is a radio virtual machine (RVM) ).

When the shadow radio platform is different from the target radio platform so that the shadow radio platform becomes a radio virtual machine, the radio virtual machine performs a virtualization function that allows the above-described config codes to operate on the actual target radio platform, End compiler that provides a just-in-time (JIT) or ahead-of-time (AOT) method of compiling code to executable code on the target radio platform.

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

A radio computer provides communication capabilities to a mobile device, which software architecture may comprise the following components.

- Radio OS

- Radio processor execution part of radio control framework

- If the Shadow Radio Platform is a Radio Virtual Machine (RVM), the implementation of the radio virtual machine,

- If the shadow radio platform is a radio virtual machine, a native implementation of the radio library (Radio Lib)

The configuration codes (config codes) of the radio applications (RAs) and the configuration codes can be provided in the form of executable code of the target radio platform or a platform independent intermediate representation (IR) format.

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

The 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 executable code for the target platform, and configcodes is equivalent to executable code for that particular platform.

A radio virtual machine is an abstraction machine that can run configcodes and is independent of any hardware. The 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 (JIT) or ahead-of-time (AOT) method for compiling configcodes into executable code.

The radio library consists of functional blocks representing a computational basis. A radio application can be represented as a collection of these interconnected functional blocks. The functional blocks of the radio library are expressed as a normative language. The native syntax of the radio library provides the executable code of the functional blocks of the library for the target platform. The radio library is extensible.

Integrated Radio Application  Operation structure

The operational structure of the integrated radio application 125 (450) can be expressed in two different cases. The first is the case where the radio application configcodes is executable code on the target platform (illustrated in FIG. 15), and the second is that the radio application configcodes is an Intermediate Representation (IR) code that is back-end compiled in the given mobile device (Illustrated in Fig. 16).

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

Referring to FIG. 15, radio libraries and User Defined Function Blocks (UDFBs) required 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 perform a given radio application (s) are included in the radio application's configcodes and back-end compiled by the radio virtual machine (see FIG. 16). In this case, since the radio library can not be included in the radio application configcodes, the native implementation of the radio library must be prepared separately in the given mobile device. In general, the native implementation of the radio library is provided by programmable hardware because the radio library contains standard function blocks (SFB) implemented on programmable hardware.

A radio library (native implementation) that can be implemented without using hardware accelerators is needed to improve the speed of standard functional blocks and to combine accelerators and program code to generate other standard functional blocks.

In both cases where the radio application configcodes are executable code or intermediate representation code, the standard function blocks are supported by hardware accelerators via the radio hardware abstraction layer (HAL) 124. This means that whenever the standard function blocks implemented by the hardware logic are invoked by the given radio application codes, the radio application configcodes may be implemented directly on the corresponding hardware accelerator over the radio HAL, either executable code or intermediate representation code . As described below, the radio HAL may also include a hardware abstraction for interfaces prepared for user defined function block libraries.

Standard functional blocks may be implemented in functional blocks commonly used in many radio applications, such as FFT (Fast Fourier Transform) and / or any functional blocks that must be implemented very efficiently using a special purpose accelerator in a given radio platform (e.g., Turbo coders).

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 may provide standard functional blocks 517-1, 517-3 and 517-M and user defined functional blocks 517-2 and 516 to a given Radio Application Package (RAP) In association with the content of the meta data.

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

The radio virtual machine 515 is a controlled execution environment for software that affects the radio characteristics of the mobile device. Using this, we can assume that the reconfiguration software, that is, the radio applications, is loaded into the radio virtual machine.

A 'custom function block set' 451 is typically provided by a radio application provider and includes all custom function blocks used in a given radio application package. The custom function block is included with the metadata and radio controller code in the radio application package. In general, a custom function block may have dependencies on a standard function block library, since the custom function block is a modified and / or extended version of the standard function block.

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

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

The radio platform 123 may generally be configured to include both programmable hardware and hardware accelerators.

On the other hand, the 'user defined function block set (UDFB set)' 451 includes all user defined function blocks used by a given radio application. It is important that any standard function block can be modified and / or extended by replacing it with appropriate standard function blocks, i.e., modified and / or extended versions of the standard function blocks to be replaced. Thus, some user functional blocks may be good candidates for the extension of a standard functional block, meaning that they can be added later as a standard functional block. In this case, after the user functional blocks are added as standard functional blocks, they will be defined as normal standard functional blocks.

In addition, since the 'UDFB set' may be provided by the provider of the radio application (ie, the 3rd party) instead of the radio platform vendor, the radio control framework may include events and / A standard set of control interfaces such as 'start', 'stop', 'pause', 'get port' and 'initialize' must be defined for the corresponding user function blocks in order to perform basic control of the commands . The standard set of control interfaces for user functional blocks may be given separately. The radio platform 123 shown in FIG. 16 and in FIG. 17 below may include programmable hardware and hardware accelerators to implement each functional block.

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 comprising a radio processor and a given radio platform composed of various types of peripheral devices are illustrated.

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

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

This can be summarized as follows. {C: Execution codes on radio processors required to implement 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 partition of A and B can be determined by each vendor.

It also implies: {Standard functional blocks} {= standard functional blocks implemented on programmable hardware} and {standard functional blocks implemented on hardware accelerators}, {standard functional blocks implemented on programmable hardware} and {hardware accelerator standard functional blocks implemented on a hardware accelerator} are empty.

On the other hand, as mentioned above, user defined function blocks must be described using standard interfaces. It should be noted that, as shown in FIG. 17, 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 reason why the standard interfaces are classified into two groups, that is, a group corresponding to the standard functional blocks executed on the programmable hardware, and a group corresponding to the standard functional blocks executed on the hardware accelerator is that each category has advantages and disadvantages Because. The latter is typically implemented in hardware logic, which is advantageous in terms of power consumption, speed required operations, and perhaps cost effectiveness. On the other hand, the former is advantageous in flexibility because it is generally performed on a microprocessor. In terms of performance, hardware accelerators are expected to be used more widely in the early stages until programmable devices are more competitive than hardware devices. In the long term, as semiconductor technology evolves, programmable hardware-dependent standard functional blocks will become more and more prevalent over peripheral dependent standard functional blocks, and the instruction set architecture (ISA) level As shown in FIG.

The plurality of standard functional blocks illustrated herein represent the granularity of the data and are only illustrated for illustrative purposes.

radio application  Package Configuration

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

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

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 radio controller code 512. The radio application package 510 for distribution of the radio application further includes 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 is determined according to the software architecture environment described above to be included in the radio application package in the form of executable code of either the radio processor or the application processor. That is, if the radio control framework is separated into an application processor portion and a radio processor portion, the radio controller code can be composed of code running on the application processor, and if the radio control framework is implemented only on a radio processor, The controller code can be composed of code running on the radio processor. On the other hand, the custom function block code 511, as mentioned above, is included in the radio application package as the code to be executed in the radio processor in either case, as executable code, source code, intermediate representation type code executable in the radio processor .

A pipeline is a combination of a radio controller, a user defined function block, and a standard function block of a radio application for implementing transmission or reception functions of a radio application, Can be defined.

In addition, if the standard function block code is configured in the form of executable code executable on the core of the radio processor, then the radio application package 510 additionally includes a radio library 514 of executable code type, .

The radio application package 510 is generated to include a standard baseband API header 520 by the supplier and is uploaded to the server 530 and transferred from the server 530 to the operating system OS of the application processor layer of the user terminal device The user defined function block code 512 and the radio library 514 are loaded into the radio processor in the application processor with reference to the pipeline configuration metadata 513 and stored in the radio operating system of the radio processor layer Lt; / RTI >

The method of executing the radio application of the above-described embodiments may be embodied so as to be stored in a computer-readable medium (recording medium) in the form of a program or a software implementing it. The computer-readable medium may be embodied in the form of program instructions, data files, data structures, and the like, alone or in combination. Programs recorded on a computer-readable medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software.

The computer-readable medium may also 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 machine language code such as those produced by a compiler, as well as high-level language code that may be executed by a computer using an interpreter or the like. The hardware device may be configured to operate with at least one software module to perform the method of executing the radio application of the foregoing embodiments, and vice versa.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims It can be understood that

Claims (1)

A method of executing a modem-independent radio application in a terminal device,
The method comprising: communicating with a 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 using a radio frequency interface (RRFI); And
Wherein the RRFI supports at least one of 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.
How to run a radio application.

Images