WO2021054703A1 - 복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법 - Google Patents

복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법 Download PDF

Info

Publication number
WO2021054703A1
WO2021054703A1 PCT/KR2020/012453 KR2020012453W WO2021054703A1 WO 2021054703 A1 WO2021054703 A1 WO 2021054703A1 KR 2020012453 W KR2020012453 W KR 2020012453W WO 2021054703 A1 WO2021054703 A1 WO 2021054703A1
Authority
WO
WIPO (PCT)
Prior art keywords
radio
computers
functional blocks
application
integrated
Prior art date
Application number
PCT/KR2020/012453
Other languages
English (en)
French (fr)
Inventor
최승원
안흥섭
장중펑
Original Assignee
한양대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한양대학교 산학협력단 filed Critical 한양대학교 산학협력단
Publication of WO2021054703A1 publication Critical patent/WO2021054703A1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1012Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B1/00Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B1/00Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/0003Software-defined radio [SDR] systems, i.e. systems wherein components typically implemented in hardware, e.g. filters or modulators/demodulators, are implented using software, e.g. by involving an AD or DA conversion stage such that at least part of the signal processing is performed in the digital domain
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present invention relates to a reconfigurable radio device, and more particularly, in a reconfigurable radio device including a plurality of radio computers, one radio application package is distributed to a plurality of radio computers. It's about how to install it.
  • SDR Software Defined Radio
  • SDR technology reduces the fixed hardware function in the user's mobile device from a signal processing point of view, expands the hardware part programmable by radio applications, and increases the flexibility of the system by using the expanded software program capability. It's a wireless technology.
  • the structure of such an SDR terminal device must have openness, dispersibility, object-orientedness, and software controllability.
  • a multimode SDR capable of accommodating various radio standards is required for global communication. In this atmosphere, research on multimode SDR is currently being actively conducted.
  • an object of the present invention is a method of distributing one radio application package to a plurality of radio computers, and a reconfigurable method to which the method is applied when it is difficult to execute one radio application on one target radio computer. It is to provide a radio device.
  • An embodiment of the present invention for achieving the object of the present invention described above is a distributed installation method of an integrated radio application in a reconfigurable radio device including a plurality of radio computers, a communication service layer, and a routing entity, the communication service Downloading a radio application package of the integrated radio application by a hierarchical administrator-the radio application package includes functional blocks constituting the integrated radio application, pipeline configuration metadata, and a radio controller code; Dividing the functional blocks into groups running on each of at least two or more of the plurality of radio computers by referring to the pipeline configuration metadata; And transmitting, by the administrator, the information on the group of functional blocks installed in each of the at least two radio computers to each of the at least two or more radio computers via the routing entity.
  • the communication service layer operates on a non-real time operating system, and each of the at least two radio computers includes a radio operating system that is a real time operating system. And, the integrated radio application may run on the at least two radio computers.
  • Each of the at least two radio computers includes a radio control framework (RCF) that provides an operating environment to the integrated radio application; The radio operation system; And at least one radio platform.
  • RCF radio control framework
  • the communication service layer may include the administrator, a mobility policy manager, a networking stack, and a monitor.
  • the manager may be a component that performs installation or removal of the integrated radio application on the at least two radio computers, and creation or deletion of an instance of the integrated radio application.
  • the manager determines a requirement for executing each of the functional blocks, a functional block execution benchmark result of each of the at least two radio computers, and data between the functional blocks.
  • the functional blocks may be divided into the groups by referring to at least one of a throughput required for traffic and control traffic.
  • a requirement for executing each of the functional blocks may be expressed in terms of an operation requirement and/or a memory requirement of each of the functional blocks expressed in asymptotic notation.
  • the functional block execution benchmark results of each of the at least two or more radio computers are received from vendors of each of the at least two or more radio computers, and a benchmark result for at least some of the functional blocks may be provided.
  • the manager is an identifier (ID) of the radio application package, a target radio computer Information including the ID of the target radio computer, pipeline configuration information of the target radio computer, and IDs of functional blocks installed in the target radio computer may be transmitted to the target radio computer via the routing entity.
  • ID identifier
  • a target radio computer Information including the ID of the target radio computer, pipeline configuration information of the target radio computer, and IDs of functional blocks installed in the target radio computer may be transmitted to the target radio computer via the routing entity.
  • the radio controller code is a component that operates in a non-real time domain and processes context information, and is included in the radio application package in the form of executable code, and the radio controller code is the function block Among them, a radio computer in which a functional block providing context information referenced by the radio controller is installed, or a radio computer in which the most functional blocks of the integrated radio application are installed.
  • a reconfigurable radio device comprising: a plurality of radio computers; A communication service layer including an administrator, a mobility policy manager, a networking stack, and a monitor; And a routing entity for performing communication between the plurality of radio computers and the communication service layer, wherein the manager comprises functional blocks constituting an integrated radio application, pipeline configuration metadata, and a radio controller code.
  • Download a radio application package including, and divide the functional blocks into groups executed in each of at least two or more radio computers among the plurality of radio computers with reference to the pipeline configuration metadata, and the administrator performs the routing Information on the group of functional blocks installed in each of the at least two radio computers may be transmitted to each of the at least two or more radio computers via an entity.
  • the communication service layer operates on a non-real time operating system, and each of the at least two radio computers has a radio operating system that is a real time operating system. Including, the integrated radio application may run on the at least two radio computers.
  • Each of the at least two radio computers includes a radio control framework (RCF) that provides an operating environment to the integrated radio application; The radio operation system; And at least one radio platform.
  • RCF radio control framework
  • the manager may select among the requirements for executing each of the functional blocks, a result of the functional block execution benchmark of each of the at least two radio computers, and the throughput required for data traffic and control traffic between the functional blocks.
  • the functional blocks may be divided into the groups with reference to at least one.
  • a requirement for executing each of the functional blocks may be expressed in terms of an operation requirement and/or a memory requirement of each of the functional blocks expressed in asymptotic notation.
  • the functional block execution benchmark results of each of the at least two or more radio computers are received from vendors of each of the at least two or more radio computers, and a benchmark result for at least some of the functional blocks may be provided.
  • the manager sends information including the identifier (ID) of the radio application package, the ID of the target radio computer, the pipeline configuration information of the target radio computer, and the ID of functional blocks installed in the target radio computer via the routing entity. It can be delivered to the target radio computer.
  • ID the identifier
  • the manager sends information including the identifier (ID) of the radio application package, the ID of the target radio computer, the pipeline configuration information of the target radio computer, and the ID of functional blocks installed in the target radio computer via the routing entity. It can be delivered to the target radio computer.
  • the radio controller code is a component that operates in a non-real time domain and processes context information, and is included in the radio application package in the form of executable code, and the radio controller code is the function block Among them, a radio computer in which a functional block providing context information referenced by the radio controller is installed, or a radio computer in which the most functional blocks of the integrated radio application are installed.
  • an integrated radio application it is possible to develop and distribute radio applications that can be executed on various radio platforms.
  • FIG. 1 is a conceptual diagram showing an architecture of a reconfigurable radio device according to embodiments of the present invention.
  • FIG. 2 is a conceptual diagram illustrating a communication service layer and a routing entity for communication with each radio computer in the architecture of a reconfigurable radio device according to embodiments of the present invention.
  • FIG. 3 is a conceptual diagram illustrating multi-radio applications in an architecture of a reconfigurable radio device according to embodiments of the present invention.
  • FIG. 4 is a conceptual diagram illustrating an example of a system architecture of a radio computer according to embodiments of the present invention.
  • FIG. 5 is a conceptual diagram illustrating another example of a system architecture of a radio computer according to embodiments of the present invention.
  • 6 to 10 are conceptual diagrams for explaining a distribution/execution process of an integrated radio application according to embodiments of the present invention.
  • 11 to 13 are conceptual diagrams for explaining an operation structure of an integrated radio application according to embodiments of the present invention.
  • FIG. 14 is a conceptual diagram illustrating an implementation of functional blocks on a radio computer according to embodiments of the present invention.
  • UML 15 is a block diagram of a Unified Modeling Language (UML) class of interfaces of a reconfigurable radio device according to embodiments of the present invention.
  • UML Unified Modeling Language
  • FIG. 16 is a conceptual diagram illustrating an interconnection between a communication service layer (CSL) using gMURI and a radio control framework (RCF) in a reconfigurable radio device according to embodiments of the present invention.
  • CSL communication service layer
  • RCF radio control framework
  • 17 is a conceptual diagram illustrating a routing entity and a switch of each radio computer in the architecture of a reconfigurable radio device according to embodiments of the present invention.
  • FIG. 18 is a conceptual diagram illustrating a pipeline configuration and a pipeline metadata format of a radio application package according to an embodiment of the present invention.
  • 19 is a conceptual diagram illustrating a configuration of a radio application package and a pipeline configuration of a target radio application according to an embodiment of the present invention.
  • 20 is a conceptual diagram for explaining the structure of a functional block.
  • 21A and 21B are conceptual diagrams for explaining throughput of data traffic and control traffic required according to dividing points of functional blocks.
  • The'terminal' used in this application is a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal (AT), a terminal, a subscriber unit, It may be referred to as a Subscriber Station (SS), a wireless device, a wireless communication device, a wireless transmit/receive unit (WTRU), a mobile node, a mobile or other terms.
  • Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a personal portable terminal (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, and a digital camera having a wireless communication function.
  • The'base station' used in this application generally refers to a fixed or moving point communicating with a terminal, and a base station, node-B, eNode-B, BTS (base transceiver system), access point (access point), relay (relay), femto-cell (femto-cell), and the like may be collectively referred to as terms.
  • Baseband parameter aggregation A unit that collects all context information to be delivered to a monitor.
  • the BPA unit may convert the context information into metric(s) to consume a minimum bandwidth in the process of transmitting the context information to the monitor.
  • Metrics may include Received Signal Strength Indication (RSSI) measurement, multi-RAT (multi-RAT) performance metric, and the like.
  • RSSI Received Signal Strength Indication
  • multi-RAT multi-RAT
  • Communication services layer A layer related to communication services that support generic applications.
  • the communication service layer may support general applications such as Internet access.
  • the communication service layer may include an administrator, a mobility policy manager, a networking stack, and a monitor.
  • Communication resources A hardware part of a radio device operating under the control of an operating system (OS), and a radio application can be executed on a communication resource.
  • OS operating system
  • Configcodes Codes that compile the source code of a radio application.
  • the configuration codes are configuration codes of a radio virtual machine (RVM) or executable codes for a specific target platform.
  • RVM radio virtual machine
  • a radio application provider When a radio application provider generates high level code based on a specific target platform, it may be directly executed on the target platform as a result of compiling the source code of the radio application.
  • an intermediate representation is obtained as a result of front-end compilation of the source code of the radio application. representation, IR) code. In this case, it must be back-end compiled for operation on a specific target platform.
  • Data flow A logical channel between the flow controller and the integrated radio application, used to transmit data elements (octets, packets, etc.) to the integrated radio application or to receive data elements from the integrated radio application.
  • data elements octets, packets, etc.
  • Distributed computations Refers to the computational model between components located on networked computers, and the operation of the components communicates messages with each other to achieve a common purpose. Can be adjusted.
  • Environmental information A set of values that can affect the execution of a radio application on a radio computer.
  • the environment information may be composed of information on the execution of the radio application, for example, information such as buffer overflow and resource allocation.
  • Functional block Functions for real-time implementation of radio application(s).
  • the functional block is a layer 1 (layer1, L2), layer 2 (layer2, L2) and layer 3 (layer3, L3) modem functions as well as all controls that must be processed in real time to implement a given radio application(s). May contain functions.
  • Functional blocks can be classified into standard functional blocks (SFBs) and user defined functional blocks (UDFBs).
  • SFB is Forward Error Correction (FEC), fast Fourier Transform (FFT)/Inverse fast Fourier Transform (IFFT), (de)interleaver, turbo coding, Viterbi coding. , Multiple Input Multiple Output (MIMO), beamforming, etc. may be common types of SFB.
  • FEC Forward Error Correction
  • FFT fast Fourier Transform
  • IFFT Inverse fast Fourier Transform
  • MIMO Multiple Input Multiple Output
  • beamforming etc.
  • -UDFB may include functional blocks dependent on a specific radio application.
  • the UDFB may be used to support a specific function(s) required for a specific radio application or a specific algorithm used to improve performance.
  • the UDFB may be used as a baseband controller function block that controls function blocks operating in real time in the baseband processor, or may be used to control context information processed in real time.
  • Each functional block may have a unique name, input, output, and properties.
  • Peer equipment The communication partner of a reconfigurable radio device.
  • the peer device may be reached by establishing a (logical) communication link (ie, association) between the reconfigurable radio device and the peer device.
  • a (logical) communication link ie, association
  • a peer device a Wide Local Area Network (WLAN) access point, an Internet Protocol (IP) access node, and the like may be included.
  • WLAN Wide Local Area Network
  • IP Internet Protocol
  • Radio application Software that generates transmitted RF signals and decodes received RF signals.
  • the software can run on a specific radio platform or RVM as part of a radio platform.
  • Radio applications can have various forms of representation.
  • Radio computer A part of the hardware of a radio device operating under the control of a radio OS (ROS), and radio applications can be executed on the radio computer.
  • Radio computers generally include programmable processors, hardware accelerators, peripherals, and the like.
  • the RF section can be regarded as part of the peripheral device.
  • Radio control framework A control framework that extends the capabilities of the OS as part of the operating system (OS) from the perspective of radio resource management.
  • the RCF may include a configuration manager (CM), a radio connection manager (RCM), a flow controller (FC), and a multiradio controller (MRC).
  • CM configuration manager
  • RCM radio connection manager
  • FC flow controller
  • MRC multiradio controller
  • RM resource manager
  • Radio Controller A functional element of a radio application that delivers context information of a radio application to a monitor.
  • An RC operating on a non-real time computational resource can access an RA operating in real time on a radio computer.
  • the monitor that receives the context information using the RC manages the context information (for example, terminal-centric configuration) so that applications can be executed using the context information. It can be provided to the manager (MPM).
  • MPM manager
  • RF Transceiver The part of a radio platform that converts a baseband signal to a radio signal for transmission and a radio signal to a baseband signal for reception.
  • Radio Library A library of SFBs provided by platform vendors as platform-specific executable code. SFBs implement reference codes of general functions for radio signal processing. When the SFB is implemented on a hardware accelerator, it is implemented through a radio hardware abstraction layer (HAL). Radio HAL is part of the ROS.
  • HAL radio hardware abstraction layer
  • ROS Radio Operating System
  • RCF Radio Operating System
  • Radio platform The piece of radio political hardware involved in radio processing power. For example, it may include programmable components, hardware accelerators, RF transceiver and antenna(s).
  • the radio platform may be parts of hardware that have the ability to generate RF signals and receive RF signals. It may be fixed accelerators (eg, Application-Specific Integrated Circuit (ASIC) or reconfigurable accelerators (eg, FPGAs), etc.).
  • ASIC Application-Specific Integrated Circuit
  • FPGAs reconfigurable accelerators
  • RVM Radio Virtual Machine
  • Reconfigurable radio equipment A radio device with radio communication capabilities that provides support for radio reconfiguration.
  • the reconfigurable radio device may be a smart phone, a feature phone, a tablet, a laptop, a connected vehicle communication platform, a network platform, an IoT device, or the like.
  • an example of a representative reconfigurable radio device including a plurality of radio computers may be a Cloud Radio Access Network.
  • various embodiments of the reconfigurable radio device are not limited thereto.
  • Shadow radio platform A platform in which configuration codes can be directly executed when corresponding to a target radio platform, and configuration codes are compiled and executed when corresponding to RVM.
  • the front-end compiler When the shadow radio platform is equivalent to the target radio platform, the front-end compiler generates executable code for the target radio platform, and the configuration code is equivalent to the executable code of the radio platform.
  • FIG. 1 is a conceptual diagram showing an architecture of a reconfigurable radio device according to embodiments of the present invention.
  • a reconfigurable radio equipment 100 may include at least one radio computer (eg, 120, 130, 140).
  • the reconfigurable radio device 100 may include the following components.
  • CSL 110 is a layer related to communication services supporting generic applications as described above.
  • the communication service layer may include four sub-elements of an administrator 111, a mobility policy manager (MPM) 112, a networking stack 113, and a monitor 114 as logical entities.
  • MPM mobility policy manager
  • the communication service layer may operate on a non-real time operating system in a separate processor (eg, application processor, AP) different from the radio computer.
  • AP application processor
  • Each radio control framework includes a configuration manager (CM), a radio connection manager (RCM), a flow controller (FC), a multiradio controller (MRC), and a resource manager (Resource Manager). Manager, RM).
  • CM configuration manager
  • RCM radio connection manager
  • FC flow controller
  • MRC multiradio controller
  • RM resource manager
  • UMA -Unified Radio Applications
  • the radio application may be provided by the same or different radio application vendor as the vendor of the reconfigurable radio device.
  • at least one integrated radio application may be executed at the same time.
  • -A radio platform (RP; 123, 133, 143) is a component including a baseband processing function and an RF transceiver, and may be included in each radio computer. Meanwhile, when the radio platform is composed of a plurality of baseband processors and/or RF transceivers, the reconfigurable radio device may support computational/spectral load balancing.
  • MURI Multiradio Interface
  • RRFI Radio Frequency Interface
  • FIG. 2 is a conceptual diagram illustrating a communication service layer and a routing entity for communication with each radio computer in the architecture of a reconfigurable radio device according to embodiments of the present invention.
  • the communication service layer is a layer related to communication services that supports higher general applications and supports specific applications related to multiple radio applications.
  • the communication service layer 110 When the radio device supports a plurality of radio computers (120, 130, 140), the communication service layer 110 generates not only a command for each radio computer, but also an identifier (ID) of each radio computer. I can.
  • the routing entity 210 is a component for routing a message generated by a communication service layer to a corresponding radio computer. The routing entity 210 may transmit a command generated from a communication service layer to a corresponding radio computer according to the ID of the radio computer.
  • the communication service layer can have its own IP address.
  • a management entity above the communication service layer (that is, it exists above L3 and is independent of the communication service layer) may interact with the communication service layer using an IP address.
  • a network function virtualization (NFV) orchestrator may be connected to the communication service layer through an IP address of the communication service layer.
  • NFV network function virtualization
  • the communication service layer 110 may include the following four components.
  • the administrator component may include at least functions for requesting installation or uninstallation of the integrated radio application and functions for creating or deleting instances of the integrated application.
  • the manager component can provide information about integrated applications, information about their status, and the like.
  • the manager component may store related radio application packages (RAP), configuration parameters, and installation and execution history of integrated applications. If required, the manager component can fall back the system to a previous snapshot.
  • RAP radio application packages
  • the mobility policy manager includes at least functions for monitoring the radio environment and the capability of the radio device in order to request activation or deactivation of an integrated application and provide a list of integrated applications. can do.
  • the mobility policy manager can perform selection of various radio access technologies (RATs), discovery and connection of peer devices.
  • the mobility policy manager may perform computation/spectral load balancing between baseband processors and RF transceivers.
  • the networking stack may include at least functions for transmitting and receiving user data.
  • the monitor component may at least contain functions for transferring information from the integrated application to the user or to an appropriate destination entity. In addition, when distributed computation is applied, the monitor may receive the computation/spectral resource usage status.
  • the radio control framework can provide a uniform way to access the functions of the radio computer and individual radio applications, as well as the general operating environment of the integrated radio application.
  • the radio control framework can provide services to the communication service layer through MURI.
  • the radio control framework may include the following five components to manage integrated radio applications.
  • CM Configuration Manager
  • the radio connection manager may at least include a function of activating/deactivating an integrated radio application according to a user request and management of a user data flow.
  • the flow controller may include at least functions for managing the transmission and reception of user data packets and the flow of signaling packets.
  • a multiradio controller schedules requests for radio resources by simultaneously executing integrated radio applications and detects and manages interactivity problems between concurrently executed integrated radio applications. It may include at least functions for. In addition, when distributed computing is applied, the multi-radio controller may include a function of reporting a spectrum resource use state.
  • the resource manager manages computational resources, shares computational resources between active integrated applications at the same time, and at least supports functions to ensure their real-time execution.
  • the resource manager may include a function of reporting a state of use of computing resources.
  • a radio control framework that expresses the functionality provided by a radio computer may require that all radio applications share a common reconfiguration, multiradio implementation, and resource sharing strategy framework.
  • Radio applications may be referred to as unified radio applications (URA) because all radio applications have a common behavior in terms of a reconfigurable radio device. Services related to activation/deactivation, peer device discovery, and maintenance of communication over user data flows may be provided through the URAI, an interface between the URA and the RCF.
  • URA unified radio applications
  • FIG. 3 is a conceptual diagram illustrating multi-radio applications in an architecture of a reconfigurable radio device according to embodiments of the present invention.
  • the reconfigurable radio device may include at least one radio computer 120, 130, and 140.
  • the operation of computing resources may be performed by a given operating system, and preferably may be performed on a non-real time basis.
  • operations of radio computers may be performed by a separate operating system that supports real-time operations of an integrated radio application.
  • the operating system of the radio computer may be referred to as a radio OS (ROS), and may belong to each radio computer.
  • ROS radio OS
  • Computing resources may include the following components.
  • the OS may include a computational resources part of the radio control framework.
  • RC Radio Controller
  • the radio computer(s) may include the following components.
  • the five components of the radio control framework can be classified into groups related to real-time execution and groups related to non-real-time execution. Which components relate to real-time execution and non-real-time execution may vary from vendor to vendor.
  • FIG. 4 is a conceptual diagram illustrating an example of a system architecture of a radio computer according to embodiments of the present invention
  • FIG. 5 is a conceptual diagram illustrating another example of a system architecture of a radio computer according to embodiments of the present invention to be.
  • a back-end compiler exists in each radio computer.
  • the back-end compiler exists on the cloud.
  • the back-end compiler can be managed on the cloud rather than on each radio computer.
  • the radio computer provides communication capabilities for a reconfigurable radio device, and may include the following components depending on the type of reconfigurable radio device.
  • Radio application configcodes which are executable code, source code or IR code
  • RVM Radio Virtual Machine
  • the radio library is native implementation.
  • the integrated radio application setting code may be an executable code or may be interpreted by a radio virtual machine.
  • the front-end compiler may generate executable code for the target platform, and the configuration code may be equivalent to the executable code of the target platform.
  • the radio library native implementation and back-end compiler shown in Fig. 4 are not required in the radio computer.
  • the radio virtual machine is an abstract machine that can execute configuration code and is hardware-independent.
  • the implementation of the radio virtual machine is specific to the target radio computer and includes a back-end compiler that provides a Just-in-Time (JIT) or Ahead-of-Time (AOT) method for compiling configuration code into executable code. can do.
  • JIT Just-in-Time
  • AOT Ahead-of-Time
  • the back-end compiler can be implemented in the following two ways. That is, an integrated radio application may be compiled within a given radio device, or an integrated radio application may be compiled on a cloud.
  • the radio library native implementation and the back-end compiler may exist in the radio computer. Accordingly, in this case, the integrated radio application setting code can be downloaded to the radio computer in the form of source code or IR, and is converted into a corresponding executable code through a back-end compiler in the radio computer. In this case, the back-end compiler may be part of the radio virtual machine.
  • the compilation process may be performed in the cloud 510 rather than the radio computer. Accordingly, the integrated radio application setting code is downloaded to the radio computer in the form of an executable code that is a result of the radio being compiled in the cloud.
  • the platform vendor must provide a native implementation of a back-end compiler and/or radio library to the cloud according to its radio platform.
  • the radio library native implementation should be provided to the cloud or radio device in the case of static/dynamic linking to be described later.
  • the radio library can be composed of SFBs.
  • One radio application can be expressed as a set of interconnected SFBs and UDFBs.
  • SFBs provided from the normative description of the radio library can be expressed in a platform-independent normative language.
  • the radio library native implementation can be provided with platform-specific codes of SFBs from the library for the target platform.
  • the radio library is extensible.
  • a radio application store may have a radio programming interface (RPI).
  • RPI radio programming interface
  • Radio applications mounted on a reconfigurable radio device may be referred to as unified radio applications (URA).
  • UAA unified radio applications
  • the process of distributing and executing integrated radio applications may consist of three stages: a design time, an installation time, and a run time.
  • 6 to 10 are conceptual diagrams for explaining a distribution/execution process of an integrated radio application according to embodiments of the present invention.
  • 6 to 10 show a process of distributing/executing a radio application in the form of a platform-specific executable code, a process of distributing/executing a radio application in the form of a platform-independent source code, and a platform-independent IR code form. Describes the process of distributing/executing radio applications.
  • the radio application code provider may generate a radio application package (RAP).
  • RAP may include meta data for pipeline configuration and radio application codes.
  • the radio controller code is part of the radio application code.
  • the radio controller code can be compiled to run on a given computing resource before being included in the RAP.
  • the RAP can be downloaded from the RadioApp Store and installed on a reconfigurable radio device.
  • the radio application code and metadata eg, for pipeline configuration
  • the radio controller code included in the RAP may be installed in a reconfigurable radio device.
  • Function blocks such as SFBs and UDFBs must be installed in the radio computer to be processed in real time, but radio controller code operating in the non-real time domain for operations that do not necessarily require real-time processing such as context information processing. Can be installed on computing resources.
  • configuration codes executable in a given reconfigurable radio device are distributed.
  • the functional blocks (SFBs and UDFBs) are executed on the radio computer.
  • Functional blocks are compiled at the design stage for each target platform to generate the corresponding configuration code. That is, SFBs and UDFBs are precompiled according to a given radio computer and included in the RAP at design time.
  • configuration codes including UDFBs and SFBs can be installed and loaded in a reconfigurable radio device to operate in a radio OS.
  • the radio application code may include only the radio controller code and UDFB codes.
  • metadata can provide information for efficient compilation. Function calls of SFBs required for execution of the target integrated radio application may be included in the configuration code.
  • the configuration code composed of UDFBs is compiled in the cloud or radio device reconfigurable during the installation phase.
  • the native implementation of SFBs is completed before the execution phase and included in the native library.
  • FIG. 7 is a case of static linking, and linking of UDFBs and SFBs may be performed in an installation step. Codes compiled in the execution phase can be loaded so that they can be executed on the ROS. 8 shows that in the case of dynamic linking, linking of UDFBs and SFBs may be performed in an execution step.
  • the radio application code may be selectively encrypted.
  • the radio application code is encrypted, the corresponding configuration code must be decrypted prior to compilation at the installation stage.
  • radio application configuration codes including UDFBs can be front-end compiled at the design stage.
  • Front-end compiled configuration codes can be back-end compiled in a reconfigurable radio device at the installation stage and converted into executable code specific to a given radio computer.
  • the native implementation of SFBs can be completed before the execution phase and included in the native library.
  • FIG. 9 is a case of static linking, and linking of UDFBs and SFBs may be performed in an installation step.
  • the back-end compiled code can be loaded so that it can be executed on the ROS.
  • 10 shows that in the case of dynamic linking, linking of UDFBs and SFBs may be performed in an execution step.
  • the operational structure of the integrated radio application is described.
  • the radio device includes one radio computer. That is, the same operation structure may be applied to each radio computer in the radio device. The following two cases are considered.
  • the integrated radio application setting code is a code that can be executed on a given radio device
  • the integrated radio application setting code is source code or IR that must be compiled on a given radio device
  • 11 to 13 are conceptual diagrams for explaining an operation structure of an integrated radio application according to embodiments of the present invention.
  • SFBs can be classified into two groups. That is, one group is a group of SFBs that require a dedicated hardware accelerator, and the other group is a group of SFBs that do not require a dedicated hardware accelerator. If a dedicated hardware accelerator is used, the hardware accelerator can be accessed through the radio HAL. In other cases, platform specific code is provided by the radio library for the associated SFB.
  • FIG. 11 an operation structure of an integrated radio application when an integrated radio application setting code is given as a code executable in a given radio device is illustrated.
  • SFBs and UDFBs necessary to execute a given integrated radio application are already included in the executable configuration code of the integrated radio application.
  • an operation structure of an integrated radio application in case an integrated radio application setting code is a source code or IR to be compiled in a given radio device is illustrated.
  • the UDFBs 45 necessary to execute a given integrated radio application are included in the configuration code of the integrated radio application, and are compiled by a compiler (in the case of a source code) or a back-end compiler (in the case of an IR).
  • a compiler in the case of a source code
  • a back-end compiler in the case of an IR
  • the radio library contains SFBs implemented on the radio computer, the native implementation of the radio library is provided by the radio computer vendor.
  • SFBs may be implemented without using a hardware accelerator, or may be implemented to create other SFBs by combining a hardware accelerator and program code.
  • the integrated radio application can be configured using an executable code and an IR code.
  • the operation procedure of the executable code in this case is the same as the case disclosed in FIG. 11.
  • the IR part of the integrated radio application can be processed in the radio virtual machine. In this way, the IR part can be executed in the execution phase.
  • the radio virtual machine is an interpreter and can be implemented with, for example, a just-in-time compiler.
  • the radio HAL contains a hardware abstraction for the implementation of SFBs using a hardware accelerator. This means that whenever SFBs implemented using the hardware accelerator(s) are called by a given integrated radio application code, they must be implemented directly on the corresponding hardware accelerator through the radio HAL. As described below, the radio HAL should also include a hardware abstraction for UDFBs, at least one consisting of a set of SFBs implemented using a hardware accelerator.
  • SFBs are functional blocks commonly used in many radio applications-e.g., Fast Fourier Transform (FFT)-and/or any functional blocks that must be implemented very efficiently using a special purpose accelerator in a given radio platform-e.g., It can be a turbo coder.
  • FFT Fast Fourier Transform
  • SFBs can be implemented in software or dedicated hardware.
  • the'user function block set (UDFB set)' shown in FIG. 12 includes UDFBs used by a given radio application(s). It is important to note that any SFB can be modified and/or extended by replacing it with an appropriate UDFB. Therefore, UDFBs can be good candidates for the expansion of SFBs, which means that they can be added as SFBs in the future. In this case, after the UDFBs are added as SFBs, they will be defined as normal SFBs. Since the'UDFB set' can be provided by the provider of the radio application (i.e., 3rd party) instead of the radio platform vendor, the radio control framework provides basic control of all UDFB events and/or commands. In order to be able to perform, a standard set of control interfaces such as'start','stop','pause','get port' and'initialize' may have to be specified for the corresponding UDFBs.
  • a standard set of control interfaces such as'start','stop','pause','get port
  • the operation structure of the integrated radio application of FIGS. 11 to 13 may include the following components.
  • the integrated radio application may include SFB(s) and UDFB(s) according to the content of metadata of a given RAP.
  • the radio library may contain platform-specific code of SFBs implemented on a radio computer. SFBs implemented using a hardware accelerator are supported through the radio HAL. In this case, the radio library may generally contain a function call to access the hardware accelerator(s).
  • UDFB set may include all UDFBs used by a given integrated radio application, and may generally be provided by a radio application provider. UDFBs are included in RAP along with metadata and radio controller code. In general, since UDFB is a modified and/or extended version of SFB, UDFB may have dependencies on SFBs.
  • Radio HAL abstracts the radio platform.
  • Radio HAL supports SFBs implemented using a dedicated hardware accelerator so that SFBs can be executed directly on the corresponding dedicated hardware accelerator(s).
  • the radio platform driver is a hardware driver used by the radio OS to access the radio platform.
  • the radio platform can generally be comprised of all RF transceivers, antennas, fixed and/or configurable hardware accelerator(s), and/or programmable IP core(s).
  • FIG. 14 is a conceptual diagram illustrating an implementation of functional blocks on a radio computer according to embodiments of the present invention.
  • the number of SFBs for programmable components may be M1, and the number of SFBs requiring a dedicated hardware accelerator may be M2. Therefore, the number M of all SFBs may be M1+M2.
  • some SFBs eg, FFT, turbo decoder, MIMO decoder, etc.
  • These SFBs executed by these hardware accelerators are supported by the radio HAL for implementation on the corresponding dedicated accelerator. This means that when each SFB implemented on a dedicated accelerator is called in an integrated radio application, it must be directly implemented on a corresponding dedicated accelerator through a radio HAL.
  • operations provided by SFBs such as bit-reverse, multiply and accumulation, for example, can be implemented in programmable components.
  • the SFB/UDFB executable codes required on the radio computer consist of the following two parts.
  • One part is executable code running on programmable components, and the other part is radio HAL codes running on dedicated accelerators.
  • ⁇ SFB/UDFBs ⁇ ⁇ SFB/UDFBs implemented on programmable components ⁇ and ⁇ SFB/UDFBs implemented on dedicated hardware accelerators ⁇ , and ⁇ SFB/UDFBs implemented on programmable components ⁇ and The intersection of ⁇ SFB/UDFBs requiring a dedicated hardware accelerator ⁇ becomes an empty set.
  • SFBs are classified into two groups-a group requiring a dedicated hardware accelerator and a group not requiring a dedicated hardware accelerator-is because each category has its own strengths and weaknesses.
  • the former is usually implemented with dedicated hardware logic, so it is advantageous in terms of power consumption, speed-demanding operation, and possibly cost-effectiveness.
  • the latter is advantageous in terms of flexibility because it is generally performed on a microprocessor.
  • dedicated hardware accelerators will be used relatively more widely in an early stage. As semiconductor technology evolves more and more, SFBs for programmable components will gradually become more dominant.
  • each baseband unit can be viewed as a single radio computer.
  • Each baseband unit of the existing cloud radio access network ran an LTE radio application, so that each baseband unit served as an LTE base station.
  • LTE base stations try to download and run 5G NR radio applications to each baseband unit in order to play the role of 5G NR base stations. It may be too high to run one 5G NR radio application on one baseband unit.
  • the radio application may be distributed and executed by using a method of distributing and installing the 5G NR radio application proposed in the present invention to each radio computer, that is, a baseband unit.
  • each baseband unit of the cloud radio access network is already serving as an LTE base station by executing an LTE radio application
  • the reconfigurable radio device can simultaneously execute multiple/multiple radio applications and change the settings of radio computers using a radio application package (RAP).
  • All radio applications may be referred to as Unified Radio Applications (URAs) when they represent a common attribute or characteristic in terms of requirements related to radio reconfiguration of a radio device.
  • URAs Unified Radio Applications
  • a reconfigurable radio device includes a communication service layer (CSL), a radio control framework (RCF), and a radio platform. ) And 4 sets of interfaces for their interconnection.
  • CSL communication service layer
  • RCF radio control framework
  • Mobile Device Architecture is a generalized multi-radio interface (gMURI), a generalized reconfigurable radio frequency interface (gRRFI), and a generalized unified radio application interface. , gURAI), and a generalized Radio Rrogramming Interface (gRPI).
  • gMURI generalized multi-radio interface
  • gRRFI generalized reconfigurable radio frequency interface
  • gRPI generalized Radio Rrogramming Interface
  • gMURI is an interface between the communication service layer and the radio control framework.
  • gRRFI is an interface between an integrated radio application and an RF transceiver.
  • gURAI is the interface between the integrated radio application and the radio control framework.
  • gRPI is an interface for independent and uniform production of radio applications.
  • UML 15 is a block diagram of a Unified Modeling Language (UML) class of interfaces of a reconfigurable radio device according to embodiments of the present invention.
  • UML Unified Modeling Language
  • Information models and protocols related to gRRFI, gMURI, gURAI, and gRPI can be defined using a unified modeling language (UML), but are not limited thereto, and other modeling languages may be used. .
  • UML unified modeling language
  • the reconfigurable radio device may include a collection of radio computers when individual integrated radio applications are designed as predetermined software entities.
  • the radio computer class is a UML class of a radio computer interface connected to gMURI (IgMURI), a UML class of a radio computer interface connected to gRRFI (IgRRFI), and a UML class of a radio computer interface connected to gURAI ( IgURAI), and a UML class of radio computer interfaces (IgRPI) related to gRPI.
  • FIG. 16 is a conceptual diagram illustrating an interconnection between a communication service layer (CSL) using gMURI and a radio control framework (RCF) in a reconfigurable radio device according to embodiments of the present invention.
  • CSL communication service layer
  • RCF radio control framework
  • an entity for routing may exist between gMURIs.
  • the routing entity may perform routing for signaling between a communication service layer and a radio control framework, and may perform routing for data exchanged between radio computers.
  • 16 shows how the communication service layer (CSL) and the radio control framework (RCF) interact with each other using a generalized multi-radio interface (gMURI).
  • CSL communication service layer
  • RCF radio control framework
  • the entity for routing can use a commercial router device when using the TCP/IP protocol, and can become a commercial switch device when using only the Ethernet protocol without using the TCP/IP protocol.
  • the routing entity delivers the command that the communication service layer wants to transmit to each radio computer according to the ID assigned by the communication service layer to the corresponding radio computer. In the reverse process of this, the routing entity delivers the message that radio computers deliver to the communication service layer to the communication service layer.
  • gMURI can support three types of services: Administrative Services, Access Control Services, and Data Flow Services.
  • At least one or more of administrative services, access control services, and data flow services may be provided by a communication service layer (CSL).
  • the radio control framework operates on a radio computer and can provide an operating environment for a unified radio application) by interworking with the communication service layer (CSL).
  • the three types of services supported by gMURI are in more detail. Explained as follows.
  • Administrative services are used by some device configuration applications such as an administrator included in the communication service layer.
  • the administrator can install or remove a new integrated radio application on the reconfigurable radio device, and create or remove an instance of the integrated radio application. Installation and loading can take place during runtime as well as at device startup time to establish network connections when reconfiguring available integrated radio applications.
  • gMURI can detect when and how a radio device needs reconfiguration without any assumptions.
  • Access Control Services are used by the Mobility Policy Manager (MPM) to maintain user policies and references related to the use of other Radio Access Technologies (RATs) and to choose between them. . Modeling of such a reference and selection algorithm is not basically included in the scope of the present invention, but the generalized multiradio interface specification may include information exchange of RAT selection decisions between the communication service layer and the radio control framework.
  • the reference itself can be created locally in applications or end-user settings, as well as in a distributed manner from a network operator or cognitive radio management framework.
  • Data Flow Services is used by a network stack of reconfigurable radio devices, such as a Transmission Control Protocol/Internet Protocol (TCP/IP) stack.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • the data flow service can represent the configuration of (logical) link layer services, which can be provided regardless of activation of the integrated radio application.
  • 17 is a conceptual diagram illustrating a routing entity and a switch of each radio computer in the architecture of a reconfigurable radio device according to embodiments of the present invention.
  • a switch existing in each radio computer may interact with an entity for routing to transmit a result of a function block executed in the radio computer to the inside or outside.
  • the switch may be a commercial product or a virtual switch (vSwitch) implemented in software.
  • the entity for routing may receive the result of the function block executed in the radio computer where the switch is located from the switch, and forward the result to the radio computer that should receive the result.
  • an entity for routing may transfer data between a communication service layer (CSL) and a radio computer.
  • CSL communication service layer
  • FIG. 18 is a conceptual diagram illustrating a pipeline configuration and a pipeline metadata format of a radio application package according to an embodiment of the present invention.
  • the pipeline metadata 1810 of the radio application package includes information such as metadata type, name, version, number of tasks in the pipeline, parent class, and children class.
  • the pipeline metadata 1810 is a children class and may have a pipeline task 1 (1820) and a pipeline task 2 (1830).
  • Each pipeline task metadata 1820 or 1830 may include information such as a metadata type, a name, a version, the number of functional blocks, a parent class, and a children class.
  • a metadata type For example, in the metadata 1820 of task 1, there are functional blocks A1, B1, F1, and L1, so it can be confirmed that there are four functional blocks in the Children class.
  • the metadata 1830 of task 2 since the functional blocks are C1, D1, and E1, it can be confirmed that there are three functional blocks in the Children class.
  • the Children functional block class may have information such as an order of each functional block, information such as a required time required for execution of each functional block and a throughput constraint time, and information such as input and output type.
  • Each radio computer is a general indicator of computational performance.Giga FLoting point Operations per Second (GFLOPS) when the radio computer supports floating-point arithmetic, and Giga Multiply-Accumulators per Second (GMACS) when supporting fixed-number arithmetic. Should be. When installing the functional block in the radio application, such an indicator can help to determine whether the functional block can be executed after the installation.
  • GFLOPS giga FLoting point Operations per Second
  • GMACS Giga Multiply-Accumulators per Second
  • a method of distributingly installing a single radio application so that a single radio application can be distributedly executed on a plurality of radio computers may consist of the following steps.
  • the reconfigurable radio device may download a radio application package to be installed from the radio app store.
  • the radio application package may consist of functional blocks, pipeline configuration metadata, and radio controller code.
  • the radio application package may be stored in a storage medium in a reconfigurable radio device.
  • functional blocks constituting a radio application package, pipeline configuration metadata, and radio controller code may be separately stored in a storage medium.
  • An administrator of the communication service layer may divide functional blocks constituting a radio application into groups that can each be executed on one radio computer.
  • an administrator can create a pipeline configuration for a group of functional blocks of a segmented radio application for each radio computer.
  • 19 is a conceptual diagram illustrating a configuration of a radio application package and a pipeline configuration of a target radio application according to an embodiment of the present invention.
  • the radio application package 1910 may include functional blocks configuring an integrated radio application to be installed, pipeline configuration metadata, and a radio controller code.
  • An administrator of the communication service layer may check the pipeline configuration 1920 of the integrated radio application to be installed by referring to the pipeline configuration metadata of the radio application package 1910.
  • the integrated radio application to be installed is largely composed of two pipelines, and each of the pipelines is arranged in a function call order of function blocks constituting the corresponding pipeline. .
  • the administrator can divide the functional blocks constituting the integrated radio application to be installed into several groups consisting of functional blocks that can be installed in one radio computer. That is, the administrator can divide the integrated radio application into groups of functional blocks executed in each radio computer.
  • the functional blocks constituting the radio application may be divided into a group of functional blocks executed in the radio computer #1 and a group of functional blocks executed in the radio computer #2.
  • two functional block groups are installed in two radio computers is described, but the number of groups and the number of radio computers are not limited thereto.
  • the administrator may divide the functional blocks into groups in consideration of all or part of the following conditions.
  • the radio computer must be capable of executing the functional blocks contained in the corresponding group.
  • the feasibility of these functional blocks may be considered in the following aspects.
  • 20 is a conceptual diagram for explaining the structure of a functional block.
  • a function block is expressed as an interface in the form of a name (Input, Output), and may include various properties. Among these attributes, a requirement attribute for executing the corresponding functional block may also be included. For example, the requirements for executing the corresponding functional block can be expressed as an index such as the complexity of the corresponding functional block or an operation speed required by the corresponding functional block, as follows.
  • -As an example to indicate the complexity of a function block, time complexity (operation requirements according to the result of analyzing the execution time of the function block) and/or space complexity (memory requirements according to the result of analyzing the memory usage of the function block) Can be expressed in asymptotic notation.
  • a criterion that can objectively represent the complexity of a function block is needed because the complexity may vary depending on various factors such as the length of the given data or the performance of the platform on which the function block is executed.
  • the asymptotic analysis method provides a criterion for objectively comparing the amount of execution time or space used based on the given data size. There are methods such as Big O, Omega, and Theta, and each represents the intersection of the asymptotic upper limit, asymptotic lower limit, asymptotic upper limit and asymptotic lower limit, respectively.
  • MIPS instructions per second
  • FLOPS floating point operations per second
  • MACS multiply-accumulator per second
  • the CSL manager compares the computational performance of each radio computer with general indicators (MIPS, FLOPS, MACS, etc.) to determine whether the functional blocks can be installed. Can be considered.
  • the CSL administrator can determine whether the target radio computer can execute the corresponding functional block by referring to the execution result table (or'benchmark result table') of standard functional blocks provided by each radio computer vendor.
  • Each radio computer vendor can provide the execution result of standard functional blocks to the Resource Manager in the radio control framework and the administrator of the communication service layer.
  • Table 1 below is a table of execution results for each standard function block in a specific radio computer.
  • Standard function block Hardware accelerator Programmable core FFT (FFT-point: 2048) 4 EAs (throughput: 100Mbps for each, execution time: 0.01ms for each) Throughput: 20Mbps Execution time:0.2ms Computational resource utilization: 11% Memory usage: 2MB Turbo decoder (K: 6144, # of codeblocks 16, # of iterations: 6) 3 EAs (throughput: 150Mbps for each, execution time: 0.03ms for each) Throughput: 12Mbps Execution time:0.5s Computational resource utilization: 11% Memory usage: 2MB Scrambling (length: 60000) Execution time:0.02ms Computational resource utilization: 3% Memory usage: 1MB Modulation (length: 300000) Execution time:0.06ms Computational resource utilization: 4% Memory usage: 3MB
  • the benchmark result table may be expressed in a markup language, for example, SGML, TeX, SAMI, or a derivative thereof, in order to specify the data structure using tags or the like.
  • the input parameters may be different for each standard function block, and the worst case parameter that takes the most execution time in the corresponding standard function block is input as the input parameter.
  • the longest execution time in executing the LTE turbo decoder is when the length K of the code block is 6144.
  • the most complex operation of 2048 points is performed. Therefore, the result of entering 2048 as the worst case parameter is presented.
  • Results that can be presented as benchmark results may include throughput, execution time, computational resource usage, and memory usage.
  • a radio computer may consist of only a hardware accelerator, only a programmable core, or may have both a hardware accelerator and a programmable core.
  • the radio computer vendor must present all benchmark results on a device (hardware accelerator or programmable core) capable of executing standard functional blocks. It is up to the administrator to decide whether to run standard function blocks on a hardware accelerator or on a programmable core.
  • the administrator of CSL can determine whether the functional blocks can be installed by emulating the execution of the functional blocks based on the benchmark result table provided by the radio computer vendor.
  • the required throughput should not be greater than the capacity of the interface between the radio computers when the result of the functional block is to be transmitted to the functional block of another radio computer.
  • the pipeline configuration metadata constituting the radio application package may include information on the amount of data traffic and control traffic throughput required between adjacent functional blocks. If adjacent functional blocks are installed on the same radio computer, these throughput requirements need not be considered. However, when the execution result of a functional block executed in one radio computer is to be transmitted to a functional block in another radio computer, the above throughput requirements must be considered.
  • 21A and 21B are conceptual diagrams for explaining throughput of data traffic and control traffic required according to dividing points of functional blocks.
  • the radio controller code not only the functional blocks, but also the installation location of the radio controller code must be considered. In the case of a function block, it must be installed on the radio computer unconditionally in order to support real-time processing, but the radio controller code can be installed on the application processor or on the radio computer. If the distributed installation is not performed, the radio controller code may be installed in the application processor part or in the radio computer according to the internal policy of the installation of the reconfigurable radio device.
  • the functional blocks should only be installed on the radio computer.
  • Which of the plurality of radio computers to install the radio controller code depends on the context information referred to by the radio controller code.
  • the radio controller code delivers context information called block error rate (BLER) to the monitor, it can be installed in a radio computer in which a functional block just before calculating BLER is installed.
  • the radio controller code may be installed in a radio computer in which the most functional blocks of a corresponding radio application are installed.
  • it may be installed on a radio computer designated by the pipeline configuration metadata.
  • the administrator can deliver installation information to each radio computer through the entity for routing.
  • the administrator transmits a message including installation information to an entity for routing, and the entity for routing may transmit the information to each radio computer.
  • the administrator can route the InstallRAReq signaling, which includes installation information of the radio application package identifier (ID), radio computer ID, pipeline configuration information of each radio computer, and IDs of functional blocks to be installed on each radio computer. Can be passed to an entity for.
  • ID the radio application package identifier
  • IDs of functional blocks to be installed on each radio computer Can be passed to an entity for.
  • the entity for routing may transmit the installation information to the corresponding radio computer based on the radio application package ID and radio computer ID information in the InstallRAReq signaling.
  • the Configuration Manager in the radio computer receives the InstallRAReq signaling from the entity for routing and can perform the installation of functional blocks in the radio computer.
  • the administrator of CSL can transmit the radio controller code to the radio computer described above through the routing entity, and the Configuration Manager in the radio computer receives the received radio controller code. Can be installed.
  • the administrator sends a ListRAReq signal including not only the radio computer ID but also the function block ID to the entity for routing.
  • the routing entity delivers the ListRAReq signal to the radio computer based on the radio computer ID.
  • the Configuration Manager in the radio computer receives the ListRAReq signal through the routing entity, it passes the list of currently installed functional blocks or radio applications to the administrator.
  • the administrator updates the function block installation list for each radio computer for which function blocks are installed on which radio computer.
  • the methods according to the present invention may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium.
  • the computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination.
  • the program instructions recorded on the computer-readable medium may be specially designed and configured for the present invention, or may be known and usable to those skilled in computer software.
  • Examples of computer-readable media include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like.
  • Examples of program instructions include machine language codes such as those produced by a compiler, as well as high-level language codes that can be executed by a computer using an interpreter or the like.
  • the above-described hardware device may be configured to operate as at least one software module to perform the operation of the present invention, and vice versa.

Abstract

재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법은 통신 서비스 계층의 관리자가 상기 통합 라디오 어플리케이션의 라디오 어플리케이션 패키지를 다운로드하는 단계; 상기 관리자가 파이프라인 구성 메타데이터를 참조하여 상기 통합 라디오 어플리케이션의 기능 블록들을 상기 복수의 라디오 컴퓨터들 중 적어도 둘 이상의 라디오 컴퓨터들 각각에서 실행되는 그룹들로 분할하는 단계; 및 상기 관리자가 라우팅 엔티티를 거쳐 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는 단계를 포함할 수 있다.

Description

복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법
본 발명은 재구성 가능한 라디오 장치(reconfigurable radio equipment)에 관한 것으로, 더욱 상세하게는 복수의 라디오 컴퓨터(radio computer)들을 포함한 재구성 가능 라디오 장치에서 하나의 라디오 어플리케이션 패키지를 복수의 라디오 컴퓨터들에 분산적으로 설치하는 방법에 관한 것이다.
소프트웨어 정의 라디오(Software Defined Radio, SDR)는 다양한 무선 접속 환경에 유연하게 적응 가능한 시스템 구축을 위하여 개방형 구조 단일 하드웨어 플랫폼상에 객체지향 구조 응용소프트웨어(Application)를 다운로드하여 전역(global) 통신을 가능케 하는 기술이다.
SDR 기술은 신호처리 관점에서 사용자의 모바일 장치(Mobile Device)에서 고정된 하드웨어 기능을 축소하고, 라디오 어플리케이션에 의해 프로그램 가능한 하드웨어 부분을 확장하며, 확장된 소프트웨어 프로그램 능력을 이용하여 시스템의 유연성을 증대시키는 무선 기술이다.
이러한 SDR 단말기(Terminal Device)의 구조는 개방성, 분산성, 객체지향성, 소프트웨어 제어성을 구비하여야 한다. 특히, 전역 통신을 위해 여러 가지 무선 규격을 수용할 수 있는 멀티모드 SDR이 요구되고 있다. 이러한 분위기에서 현재 멀티모드 SDR에 대한 연구가 활발히 진행되고 있다.
종래 재구성 가능한 라디오 장치에서는, 하나의 라디오 어플리케이션 패키지가 단일 타겟 라디오 컴퓨터에 다운로드되고 설치되어 라디오 어플리케이션이 실행되는 것이 가정되었다. 따라서, 라디오 어플리케이션이 요구하는 성능 요구 사항을 라디오 컴퓨터의 성능이 만족하지 못할 때 해당 라디오 어플리케이션이 실행될 수 없는 문제가 있다.
따라서, 본 발명의 목적은 하나의 라디오 어플리케이션이 하나의 타겟 라디오 컴퓨터에서 실행되기 어려운 경우, 하나의 라디오 어플리케이션 패키지를 복수의 라디오 컴퓨터들에 분산적으로 설치할 수 있는 방법 및 해당 방법이 적용되는 재구성 가능한 라디오 장치를 제공하는데 있다.
상술한 본 발명의 목적을 달성하기 위한 본 발명의 일 실시예는, 복수의 라디오 컴퓨터들, 통신 서비스 계층, 및 라우팅 엔티티를 포함한 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법으로서, 상기 통신 서비스 계층의 관리자(administrator)가 상기 통합 라디오 어플리케이션의 라디오 어플리케이션 패키지를 다운로드하는 단계-상기 라디오 어플리케이션 패키지는 상기 통합 라디오 어플리케이션을 구성하는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드를 포함함; 상기 관리자가 상기 파이프라인 구성 메타데이터를 참조하여 상기 기능 블록들을 상기 복수의 라디오 컴퓨터들 중 적어도 둘 이상의 라디오 컴퓨터들 각각에서 실행되는 그룹들로 분할하는 단계; 및 상기 관리자가 상기 라우팅 엔티티를 거쳐 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는 단계를 포함할 수 있다.
상기 통신 서비스 계층은 논-리얼 타임(non-real time) 운영체제 상(operating system)에서 동작하며, 상기 적어도 둘 이상의 라디오 컴퓨터 각각은 리얼 타임(real time) 운영체제인 라디오 운영체제(radio operating system)를 포함하며, 상기 통합 라디오 어플리케이션이 상기 적어도 둘 이상의 라디오 컴퓨터에서 동작할 수 있다.
상기 적어도 둘 이상의 라디오 컴퓨터 각각은 상기 통합 라디오 어플리케이션에 동작 환경을 제공하는 라디오 컨트롤 프레임워크(radio control framework, RCF); 상기 라디오 운영체제(radio operation system); 및 적어도 하나의 라디오 플랫폼을 포함할 수 있다.
상기 통신 서비스 계층은 상기 관리자(administrator), 이동성 정책 매니저(mobility policy manager), 네트워킹 스택(networking stack), 및 모니터(monitor)를 포함할 수 있다.
상기 관리자는 상기 통합 라디오 어플리케이션의 상기 적어도 둘 이상의 라디오 컴퓨터에 대한 설치(installation) 또는 제거(uninstallation) 및 상기 상기 통합 라디오 어플리케이션의 인스턴스의 생성 또는 삭제를 수행하는 구성요소일 수 있다.
상기 기능 블록들을 상기 그룹들로 분할하는 단계에서, 상기 관리자는 상기 기능 블록들 각각을 실행하기 위한 요구 사항, 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과, 및 상기 기능 블록들 간의 데이터 트래픽 및 컨트롤 트래픽에 대해 요구되는 쓰루풋(throughput) 중 적어도 하나를 참조하여 상기 기능 블록들을 상기 그룹들로 분할할 수 있다.
상기 기능 블록들 각각을 실행하기 위한 요구 사항은 점근적 표기법(asymptotic notation)으로 표기되는 상기 기능 블록들 각각의 연산 요구 사항 및/또는 메모리 요구 사항로 표현될 수 있다.
상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과는 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 벤더(vendor)로부터 수신되며, 상기 기능 블록들 중 적어도 일부에 대한 벤치마크 결과를 제공할 수 있다.
상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는 단계에서, 상기 관리자는 상기 라디오 어플리케이션 패키지의 식별자(ID), 대상 라디오 컴퓨터의 ID, 상기 대상 라디오 컴퓨터의 파이프라인 구성 정보, 및 상기 대상 라디오 컴퓨터에 설치되는 기능 블록들의 ID를 포함한 정보를 상기 라우팅 엔티티를 거쳐서 상기 대상 라디오 컴퓨터에 전달할 수 있다.
상기 라디오 컨트롤러 코드는 논-리얼 타임 영역에서 동작하며 컨텍스트 정보(context information)를 처리하는 구성요소로서, 실행 가능한 코드(executablecode) 형태로 상기 라디오 어플리케이션 패키지에 포함되며, 상기 라디오 컨트롤러 코드는 상기 기능 블록들 중 상기 라디오 컨트롤러가 참조하는 컨텍스트 정보를 제공하는 기능 블록이 설치된 라디오 컴퓨터 또는 상기 통합 라디오 어플리케이션의 기능 블록들이 가장 많이 설치된 라디오 컴퓨터에 설치될 수 있다.
상술한 본 발명의 목적을 달성하기 위한 본 발명의 다른 실시예는, 재구성 가능한 라디오 장치로서, 복수의 라디오 컴퓨터들(radio computers); 관리자(administrator), 이동성 정책 매니저(mobility policy manager), 네트워킹 스택(networking stack), 및 모니터(monitor)를 포함하는 통신 서비스 계층(communication service layer); 및 상기 복수의 라디오 컴퓨터들과 상기 통신 서비스 계층 간의 통신을 수행하는 라우팅 엔티티(routing entity)를 포함하고, 상기 관리자는 통합 라디오 어플리케이션을 구성하는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드를 포함한 라디오 어플리케이션 패키지를 다운로드하고, 상기 파이프라인 구성 메타데이터를 참조하여 상기 기능 블록들을 상기 복수의 라디오 컴퓨터들 중 적어도 둘 이상의 라디오 컴퓨터들 각각에서 실행되는 그룹들로 분할하고, 상기 관리자가 상기 라우팅 엔티티를 거쳐 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달할 수 있다.
상기 통신 서비스 계층은 논-리얼 타임(non-real time) 운영체제 상(operating system)에서 동작하며, 상기 적어도 둘 이상의 라디오 컴퓨터의 각각은 리얼 타임(real time) 운영체제인 라디오 운영체제(radio operating system)를 포함하며, 상기 통합 라디오 어플리케이션이 상기 적어도 둘 이상의 라디오 컴퓨터에서 동작할 수 있다.
상기 적어도 둘 이상의 라디오 컴퓨터 각각은 상기 통합 라디오 어플리케이션에 동작 환경을 제공하는 라디오 컨트롤 프레임워크(radio control framework, RCF); 상기 라디오 운영체제(radio operation system); 및 적어도 하나의 라디오 플랫폼을 포함할 수 있다.
상기 관리자는 상기 기능 블록들 각각을 실행하기 위한 요구 사항, 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과, 및 상기 기능 블록들 간의 데이터 트래픽 및 컨트롤 트래픽에 대해 요구되는 쓰루풋(throughput) 중 적어도 하나를 참조하여 상기 기능 블록들을 상기 그룹들로 분할할 수 있다.
상기 기능 블록들 각각을 실행하기 위한 요구 사항은 점근적 표기법(asymptotic notation)으로 표기되는 상기 기능 블록들 각각의 연산 요구 사항 및/또는 메모리 요구 사항로 표현될 수 있다.
상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과는 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 벤더(vendor)로부터 수신되며, 상기 기능 블록들 중 적어도 일부에 대한 벤치마크 결과를 제공할 수 있다.
상기 관리자는 상기 라디오 어플리케이션 패키지의 식별자(ID), 대상 라디오 컴퓨터의 ID, 상기 대상 라디오 컴퓨터의 파이프라인 구성 정보, 및 상기 대상 라디오 컴퓨터에 설치되는 기능 블록들의 ID를 포함한 정보를 상기 라우팅 엔티티를 거쳐서 상기 대상 라디오 컴퓨터에 전달할 수 있다.
상기 라디오 컨트롤러 코드는 논-리얼 타임 영역에서 동작하며 컨텍스트 정보(context information)를 처리하는 구성요소로서, 실행 가능한 코드(executablecode) 형태로 상기 라디오 어플리케이션 패키지에 포함되며, 상기 라디오 컨트롤러 코드는 상기 기능 블록들 중 상기 라디오 컨트롤러가 참조하는 컨텍스트 정보를 제공하는 기능 블록이 설치된 라디오 컴퓨터 또는 상기 통합 라디오 어플리케이션의 기능 블록들이 가장 많이 설치된 라디오 컴퓨터에 설치될 수 있다.
본 발명의 실시예들에 따른 통합 라디오 어플리케이션의 동작 구조를 이용하면 다양한 라디오 플랫폼 상에서 수행될 수 있는, 라디오 어플리케이션의 개발 및 배포가 가능하다. 또한, 이동통신 사업자의 측면에서는, 필요에 따라 자신의 망 가입자들이 사용하고 있는 다양한 라디오 플랫폼을 구비한 단말기들을 원하는 통신망 규격으로 전환하는 것이 가능해지므로, 유연성있는 망 운영이 가능해진다. 또한, 사용자의 측면에서는 새로운 통신망으로 전환이 필요한 경우에 새로운 단말을 구입할 필요가 없이 라디오 어플리케이션 패키지를 다운로드받아 라디오 어플리케이션을 자신의 단말기에 설치하는 것만으로 새로운 통신망을 사용하는 것이 가능해진다.
도 1은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처를 도시한 개념도이다.
도 2는 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 통신 서비스 계층과 각 라디오 컴퓨터들과의 통신을 위한 라우팅 엔티티를 설명하기 위한 개념도이다.
도 3은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 멀티라디오 어플리케이션들을 설명하기 위한 개념도이다.
도 4는 본 발명의 실시예들에 따른 라디오 컴퓨터의 시스템 아키텍처의 일 예를 설명하기 위한 개념도이다.
도 5는 본 발명의 실시예들에 따른 라디오 컴퓨터의 시스템 아키텍처의 다른 예를 설명하기 위한 개념도이다.
도 6 내지 도 10은 본 발명의 실시예들에 따른 통합 라디오 어플리케이션의 배포/실행 과정을 설명하기 위한 개념도들이다.
도 11 내지 도 13은 본 발명의 실시예들에 따른 통합 라디오 어플리케이션의 동작 구조를 설명하기 위한 개념도들이다.
도 14는 본 발명의 실시예들에 따른 라디오 컴퓨터 상에서의 기능 블록들을 구현을 설명하기 위한 개념도이다.
도 15는 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 인터페이스들의 UML(Unified Modeling Language) 클래스 블록도이다.
도 16은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치에서 gMURI를 이용하는 통신 서비스 계층(CSL)과 라디오 컨트롤 프레임워크(RCF) 간의 상호 접속을 설명하기 위한 개념도이다.
도 17은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 라우팅 엔티티와 각 라디오 컴퓨터의 스위치(switch)를 설명하기 위한 개념도이다.
도 18은 본 발명의 일 실시예에 따른 라디오 어플리케이션 패키지의 파이프라인 구성 및 파이프라인 메타데이터 형식을 설명하기 위한 개념도이다.
도 19는 본 발명의 일 실시예에 따른 라디오 어플리케이션 패키지의 구성 및 대상 라디오 어플리케이션의 파이프라인 구성을 설명하기 위한 개념도이다.
도 20은 기능 블록의 구조를 설명하기 위한 개념도이다.
도 21a와 도 21b는 기능 블록들의 분할 지점에 따라서 요구되는 데이터 트래픽과 컨트롤 트래픽의 스루풋을 설명하기 위한 개념도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다.
그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
본 출원에서 사용하는 '단말'은 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선송수신유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있으나, 이에 한정되는 것은 아니다.
본 출원에서 사용하는 '기지국'은 일반적으로 단말과 통신하는 고정되거나 이동하는 지점을 말하며, 베이스 스테이션(base station), 노드-B(Node-B), e노드-B(eNode-B), BTS(base transceiver system), 액세스 포인트(access point), 릴레이(relay) 및 펨토셀(femto-cell) 등을 통칭하는 용어일 수 있다.
이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.
본 발명을 설명하기 위해서 전반적으로 사용되는 용어들에 대한 간략한 정의들을 정리한다. 아래 용어들 이외의 용어들에 대해서는 본 명세서내의 적절한 부분에서 정의를 제공한다.
베이스밴드 파라미터 집성(baseband parameter aggregation, BPA): 모니터(monitor)로 전달될 모든 컨텍스트 정보를 수집하는 유닛. BPA 유닛은 컨텍스트 정보를 컨텍스트 정보를 모니터로 전달하는 과정에서 최소의 대역폭을 소모하도록 메트릭(들)로 변환할 수 있다. 메트릭들은 Received Signal Strength Indication (RSSI) measurement, 다중 RAT(multi-RAT) 성능 메트릭 등을 포함할 수 있다.
통신 서비스 계층(communication services layer, CSL): 일반적인 어플리케이션(generic application)들을 지원하는 통신 서비스들과 관련된 계층. 예를 들어, 통신 서비스 계층은 인터넷 액세스(Internet access)와 같은 일반적인 어플리케이션을 지원할 수 있다. 통신 서비스 계층은 관리자(administrator), 이동성 정책 매니저(mobility policy manager), 네트워킹 스택 및 모니터를 포함할 수 있다.
통신 자원(computational resources): 운영체제(OS)의 제어 아래에 동작하는 라디오 장치의 하드웨어 부분이며, 라디오 어플리케이션이 통신 자원 상에서 실행될 수 있다.
설정 코드(configcodes): 라디오 어플리케이션의 소스 코드를 컴파일한 코드. 설정 코드는 라디오 가상 머신(radio virtual machine, RVM)의 설정코드(configuration codes) 또는 특정 타겟 플랫폼을 위한 실행 코드(executable codes)이다. 라디오 어플리케이션의 제공자가 특정 타겟 플랫폼에 기초한 고수준 코드(high level code)를 생성하는 경우, 라디오 어플리케이션의 소스 코드를 컴파일한 결과물로서 타겟 플랫폼에서 직접 실행될 수 있다. 따른 경우, 즉, 라디오 어플리케이션의 제공자가 특정 타겟 플랫폼을 고려하지 않은 고수준 코드(high level code)를 생성하는 경우, 라디오 어플리케이션의 소스 코드의 프론트-엔드(front-end) 컴파일 결과물로서 중간 표현(intermediate representation, IR) 코드일 수 있다. 이 경우, 특정 타겟 플랫폼 상의 동작을 위해서 백-엔드(back-end) 컴파일되어야 한다.
데이터 플로우(data flow): 플로우 컨트롤러와 통합 라디오 어플리케이션 간의 논리 채널로서, 통합 라디오 어플리케이션에 데이터 요소들(옥텟, 패킷들 등)을 전송하거나 통합 라디오 어플리케이션으로부터 데이터 요소들을 수신하는데 이용된다.
분산된 컴퓨팅(distributed computations): 네트워크-연결된 컴퓨터들(networked computers)에 위치한 컴포넌트들 간의 연산 모델(computation model)을 의미하며, 구성요소들의 동작은 공통의 목적을 달성하기 위해서 상호 간에 메시지를 주고받으면서 조정될 수 있다.
환경 정보(environmental information): 라디오 컴퓨터 상에서 라디오 어플리케이션의 실행에 영향을 미칠 수 있는 값들의 집합. 환경 정보는 라디오 어플리케이션의 실행에 미치는 정보, 예를 들면 버퍼 오버플로우(buffer overflow), 자원 할당(resource allocation) 등의 정보로 구성될 수 있다.
기능 블록(functional block, FB): 라디오 어플리케이션(들)의 리얼 타임 구현을 위한 기능들. 기능 블록은 계층1(layer1, L2), 계층2(layer2, L2) 및 계층3(layer3, L3)의 모뎀 기능들뿐만 아니라 주어진 라디오 어플리케이션(들)을 구현하기 위해서 리얼 타임으로 처리되어야 하는 모든 제어 기능들을 포함할 수 있다. 기능 블록들은 표준 기능 블록들(Standard Functional Blocks, SFBs)과 사용자 정의 기능 블록들(User Defined Functional Blocks, UDFBs)로 분류될 수 있다.
-SFB는 많은 라디오 어플리케이션들에 의해서 공유될 수 있다. 예를 들어 SFB는 순방향 오류 정정(Forward Error Correction, FEC), fast Fourier Transform (FFT)/Inverse fast Fourier Transform (IFFT), (de)interleaver, 터보 코딩(turbo coding), 비터비 코딩(Viterbi coding), Multiple Input Multiple Output (MIMO), 빔포밍(Beamforming), 등이 SFB의 일반적인 유형일 수 있다.
-UDFB는 특정 라디오 어플리케이션에 의존적인 기능 블록들을 포함할 수 있다. UDFB는 특정 라디오 어플리케이션에 필요한 특정 기능(들) 또는 성능 향상을 위해 이용되는 특정 알고리즘을 지원하기 위해서 이용될 수 있다. 또한, UDFB는 베이스밴드 프로세서에서 리얼 타임으로 동작하는 기능 블록들을 제어하는 베이스밴드 컨트롤러 기능 블록으로서 사용되거나, 리얼 타임으로 처리되는 컨텍스트 정보를 제어하기 위해서 사용될 수 있다. 각각의 기능 블록은 고유의 이름(name), 입력(input), 출력(output) 및 특성(properties)을 가질 수 있다.
피어 장치(peer equipment): 재구성 가능한 라디오 장치의 통신 상대방. 피어 장치는 재구성 가능한 라디오 장치와 피어 장치 간의 (논리적) 통신 링크 (즉, 연결(association))을 설정하는 것에 의해서 도달될 수 있다. 피어 장치의 예로서, Wide Local Area Network (WLAN) 액세스 포인트, Internet Protocol (IP) 액세스 노드 등이 포함될 수 있다.
라디오 어플리케이션(radio application): 전송 RF 신호의 생성과 수신 RF 신호의 복호를 수행하는 소프트웨어. 소프트웨어는 특정 라디오 플랫폼 또는 라디오 플랫폼의 일부로서의 RVM 상에서 실행될 수 있다. 라디오 어플리케이션들은 다양한 표현 형태(forms of representation)를 가질 수 있다.
-라디오 라이브러리 네이티브 구현(radio library native implementation)에 대한 라디오 라이브러리 호출(call) 및 라디오 HAL 호출을 포함하는 소스 코드
-라디오 라이브러리 네이티브 구현(radio library native implementation)에 대한 라디오 라이브러리 호출(call) 및 라디오 HAL 호출을 포함하는 IR 코드
-특정 라디오 플랫폼을 위한 실행코드
라디오 컴퓨터(radio computer): ROS(radio OS)의 제어 하에서 동작하는 라디오 장치 하드웨어 부분으로, 라디오 어플리케이션들이 라디오 컴퓨터 상에서 실행될 수 있다. 라디오 컴퓨터는 일반적으로 프로그래머블 프로세서들, 하드웨어 가속기, 주변장치 등을 포함한다. RF 부는 주변장치의 일부로 간주될 수 있다.
라디오 컨트롤 프레임워크(radio control framework, RCF): 운영체제(OS)의 일부로서 OS의 능력(capability)을 무선 자원 관리(radio resource management) 관점에서 확장하는 컨트롤 프레임워크. RCF는 설정 매니저(Configuration Manager, CM), 라디오 연결 매니저(Radio Connection Manager, RCM), 플로우 컨트롤러(Flow Controller, FC) 및 멀티라디오 컨트롤러(Multiradio Controller, MRC)를 포함할 수 있다. 리소스 매니저(Resource Manager, RM)는 일반적으로 OS의 일부일 수 있다.
라디오 컨트롤러(Radio Controller, RC): 라디오 어플리케이션의 컨텍스트 정보를 모니터로 전달하는 라디오 어플리케이션의 기능 요소. 논-리얼 타임 연산 자원에서 동작하는 RC는 라디오 컴퓨터 상에서 리얼 타임으로 동작하는 RA에 액세스할 수 있다. RC를 이용하여 컨텍스트 정보를 전달받는 모니터는 컨텍스트 정보를 이용하여 어플리케이션들이 수행될 수 있도록 컨텍스트 정보(예를 들면, 단말 중심의 설정(terminal-centric configuration))를 관리자(administrator) 및/또는 이동성 정책 매니저(MPM)에 제공할 수 있다.
RF 송신기(RF Transceiver): 전송을 위해서 베이스밴드 신호를 라디오 신호로 변환하고 수신을 위해서 라디오 신호를 베이스밴드 신호로 변환하는 라디오 플랫폼의 부분
라디오 라이브러리: 플랫폼 벤더(vendor)에 의해서 플랫폼-특정적인 실행 코드로 제공되는 SFB들의 라이브러리. SFB들은 라디오 신호 처리를 위해서 일반적인 기능들의 기준 코드들(reference codes)을 구현한다. SFB는 하드웨어 가속기 상에 구현될 경우, 라디오 HAL(hardware abstraction layer)를 통해서 구현된다. 라디오 HAL은 ROS의 일부이다.
라디오 OS(Radio Operating System, ROS): RCF에 의해서 권한이 부여된(empowered) OS. ROS는 라디오 플랫폼의 정통적인 관리 기능들(예컨대, 리소스 관리, 파일 시스템 지원, 하드웨어 자원들에 대한 통합 액세스, 등)에 추가적으로 RCF 기능(capabilities)을 제공한다.
라디오 플랫폼: 라디오 처리 능력에 연관된 라디오 정치 하드웨어의 부분. 예를 들어, 프로그래머블 컴포넌트들, 하드웨어 가속기들, RF 송수신기 및 안테나(들)을 포함할 수 있다. 라디오 플랫폼은 RF 신호들을 생성하고 RF 신호들을 수신하는 능력을 가진 하드웨어의 부분들일 수 있다. 고정 가속기(fixed accelerator)들(예컨대, Application-Specific Integrated Circuit (ASIC) 또는 재구성 가능 가속기(reconfigurable accelerators)들(예컨대, FPGAs) 등일 수 있다.
라디오 재구성(radio reconfiguration): 에어 인터페이스(air interface)와 관련된 파라미터들의 재구성
라디오 가상 머신(Radio Virtual Machine, RVM): 반응적이고 동시적인(reactive and concurrent) 실행을 지원하는 추상화(abstract) 머신. RVM은 베이스밴드 코드 개발의 유연성(flexibility)과 요구되는 (재)인증(certification) 노력의 트레이드-오프 선택을 허용하는 통제된 실행 환경(controlled execution environment)로서 구현될 수 있다.
재구성 가능한 라디오 장치(reconfigurable radio equipment): 라디오 재구성에 대한 지원을 제공하는 라디오 통신 능력을 가진 라디오 장치. 재구성 가능한 라디오 장치는 스마트 폰, 피쳐 폰, 태블릿, 랩톱, 연결된 차량(Connected Vehicle) 통신 플랫폼, 네트워크 플랫폼, 사물통신(IoT) 디바이스, 등일 수 있다. 또한, 복수 개의 라디오 컴퓨터를 포함하는 대표적인 재구성 가능한 라디오 장치의 예는 클라우드 무선 접속 네트워크(Cloud Radio Access Network)일 수 있다. 그러나, 재구성 가능한 라디오 장치의 다양한 실시예들은 이에 한정되지 않는다.
쉐도우 라디오 플랫폼(shadow radio platform): 타겟 라디오 플랫폼에 대응될 경우는 설정 코드들이 직접 실행될 수 있고, RVM에 대응될 경우에는 설정 코드들 컴파일되어 실행되는 플랫폼. 쉐도우 라디오 플랫폼이 타겟 라디오 플랫폼과 동등한 경우, 프론트-엔드 컴파일러는 타겟 라디오 플랫폼에 대한 실행 코드(executable code)를 생성하며, 설정 코드는 라디오 플랫폼의 실행 코드(executable code)와 동등하다.
재구성 가능한 라디오 장치의 아키텍처
도 1은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처를 도시한 개념도이다.
도 1을 참조하면, 재구성 가능한 라디오 장치(radio equipment, 100)는 적어도 하나의 라디오 컴퓨터(예컨대, 120, 130, 140)를 포함할 수 있다. 또한, 도 1에서 보여지는 바와 같이, 재구성 가능한 라디오 장치(100)는 아래와 같은 구성요소들을 포함할 수 있다.
-통신 서비스 계층(Communication Services Layer, CSL; 110)는 앞서 설명된 것과 같이 일반적인 어플리케이션(generic application)들을 지원하는 통신 서비스들과 관련된 계층이다. 통신 서비스 계층은 관리자(administrator; 111), 이동성 정책 매니저(mobility policy manager, MPM; 112), 네트워킹 스택(113), 및 모니터(114)의 4개 하부 구성요소들을 논리 엔티티들로서 포함할 수 있다. 통신 서비스 계층은 일반적으로 라디오 컴퓨터와는 다른 별도의 프로세서(예컨대, application processor, AP)에서 논-리얼(non-real time) 타임 운영체제 상에서 동작할 수 있다.
-라디오 컨트롤 프레임워크(Radio Control Framework, RCF; 121, 131, 141)는 각각의 라디오 컴퓨터에 존재할 수 있다. 각 라디오 컨트롤 프레임워크는 설정 매니저(Configuration Manager, CM), 라디오 연결 매니저(Radio Connection Manager, RCM), 플로우 컨트롤러(Flow Controller, FC) 및 멀티라디오 컨트롤러(Multiradio Controller, MRC), 및 리소스 매니저(Resource Manager, RM)를 포함할 수 있다.
-통합 라디오 어플리케이션(Unified Radio Applications, URA; 122, 132, 142)는 본 발명의 재구성 가능한 라디오 장치의 실행 대상이 되는 라디오 어플리케이션이다. 라디오 어플리케이션은 재구성 가능한 라디오 장치의 벤더와 동일하거나 다른 라디오 어플리케이션 벤더에 의해서 제공될 수 있다. 하나의 라디오 컴퓨터에서, 동시에 적어도 하나의 통합 라디오 어플리케이션이 실행될 수 있다.
-라디오 플랫폼(Radio Platform, RP; 123, 133, 143)은 베이스밴드(baseband) 처리 기능과 RF 송수신기를 포함하는 구성요소이며, 각각의 라디오 컴퓨터에 포함될 수 있다. 한편, 라디오 플랫폼이 복수개의 베이스밴드 프로세서들 및/또는 RF 송수신기들로 구성될 경우, 재구성 가능한 라디오 장치는 연산/스펙트럼(computational/spectral) 로드 밸런싱을 지원할 수 있다.
상술된 4개의 구성요소들은 다음과 같은 인터페이스들에 의해서 상호연결될 수 있다.
-다중 라디오 인터페이스(Multiradio Interface, MURI): 통신 서비스 계층과 라디오 컨트롤 프레임워크 간의 인터페이스
-통합 라디오 어플리케이션 인터페이스(Unified Radio Application Interface, URAI): 라디오 컨트롤 프레임워크와 통합 라디오 어플리케이션 간의 인터페이스
-재구성 가능한 RF 인터페이스(Reconfigurable Radio Frequency Interface, RRFI): 통합 라디오 어플리케이션과 RF 송수신기(들) 간의 인터페이스
도 2는 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 통신 서비스 계층과 각 라디오 컴퓨터들과의 통신을 위한 라우팅 엔티티를 설명하기 위한 개념도이다.
통신 서비스 계층은 상위의 일반 어플리케이션들을 지원하고 다중 라디오 어플리케이션들과 관련된 특정 어플리케이션들을 지원하는 통신 서비스들과 관련된 계층이다. 라디오 장치가 복수의 라디오 컴퓨터들(120, 130, 140)을 지원할 경우, 통신 서비스 계층(110)은 각 라디오 컴퓨터에 대한 명령(command)뿐만 아니라 각 라디오 컴퓨터의 식별자(identifier, ID)를 생성할 수 있다. 라우팅 엔티티(210)는 대응되는 라디오 컴퓨터로 통신 서비스 계층이 생성한 메시지를 라우팅하기 위한 구성요소이다. 라우팅 엔티티(210)는 라디오 컴퓨터의 ID에 따라, 통신 서비스 계층으로부터 생성된 명령을 대응되는 라디오 컴퓨터로 전달할 수 있다.
통신 서비스 계층은 자신의 IP 어드레스를 가질 수 있다. 통신 서비스 계층 상위의 관리 엔티티(즉, L3 이상에 존재하며, 통신 서비스 계층과는 독립적)는 IP 어드레스를 이용하여 통신 서비스 계층과 상호 작용할 수 있다. 예를 들어, NFV(network function virtualization) 오케스트레이터(orchestrator)는 통신 서비스 계층의 IP 어드레스를 통해서 통신 서비스 계층과 연결될 수 있다.
통신 서비스 계층(110)은 아래의 4개 구성요소들을 포함할 수 있다.
-관리자(Administrator): 관리자 구성요소는 적어도 통합 라디오 어플리케이션의 설치 또는 제거(uninstallation)를 요청하는 기능들과 통합 어플리케이션의 인스턴스들을 생성하거나 삭제하는 기능들을 포함할 수 있다. 관리자 구성요소는 통합 어플리케이션들에 대한 정보 제공, 그들의 상태에 대한 정보 등을 제공할 수 있다.
스냅샷(snapshot) 기능이 요구되는 경우, 관리자 구성요소는 관련된 라디오 어플리케이션 패키지들(radio application package, RAP), 설정 파라미터들 및 통합 어플리케이션들의 설치와 실행 관련 이력들을 저장할 수 있다. 요구되는 경우, 관리자 구성요소는 이전의 스냅샷으로 시스템을 되돌릴 수 있다(fall back).
-이동성 정책 매니저(Mobility Policy Manager, MPM): 이동성 정책 매니저는 통합 어플리케이션의 활성화 또는 비활성화를 요청하고 통합 어플리케이션 리스트를 제공하기 위해서, 적어도 라디오 환경과 라디오 장치의 캐퍼빌리티에 대한 모니터링을 위한 기능들을 포함할 수 있다. 또한, 이동성 정책 매니저는 다양한 라디오 액세스 기술들(radio access technologies, RATs)에 대한 선택, 피어 장치의 디스커버리 및 연결을 수행할 수 있다. 또한, 이동성 정책 매니저는 베이스밴드 프로세서들 및 RF 송수신기들 간의 연산/스펙트럼 로드 밸런싱을 수행할 수 있다.
-네트워킹 스택(Networking stack): 네트워킹 스택은 사용자 데이터의 전송 및 수신을 위한 기능들을 적어도 포함할 수 있다.
-모니터(Monitor): 모니터 구성요소는 적어도 통합 어플리케이션으로부터 사용자 또는 적절한 목적지 엔티티로 정보를 전달하기 위한 기능들을 포함할 수 있다. 또한, 분산된 컴퓨팅(distributed computation)이 적용될 경우, 모니터는 연산/스펙트럼 자원 사용 상태를 수신할 수 있다.
라디오 컨트롤 프레임워크는 통합 라디오 어플리케이션의 일반적인 동작 환경과 라디오 컴퓨터의 기능과 개별 라디오 어플리케이션에 액세스하기 위한 균일한 방식을 제공할 수 있다. 라디오 컨트롤 프레임워크는 MURI를 통해서 통신 서비스 계층에 서비스들을 제공할 수 있다.
라디오 컨트롤 프레임워크는 통합 라디오 어플리케이션을 관리하기 위해서 아래의 5가지 구성요소들을 포함할 수 있다.
-설정 매니저(Configuration Manager, CM): 설정 매니저는 적어도 통합 라디오 어플리케이션의 라디오 파라미터들의 관리 및 라디오 파라미터들에 대한 액세스뿐만 아니라, 통합 라디오 어플리케이션을 설치 또는 제거하고, 통합 라디오 어플리케이션의 인스턴스를 생성 또는 삭제하기 위한 기능들을 포함할 수 있다.
-라디오 연결 매니저(Radio Connection Manager, RCM): 라디오 연결 매니저는 사용자 요청 및 사용자 데이터 플로우의 관리에 따라서 통합 라디오 어플리케이션을 활성화/비활성화하는 기능을 적어도 포함할 수 있다.
-플로우 컨트롤러(Flow Controller, FC): 플로우 컨트롤러는 사용자 데이터 패킷의 전송 및 수신과 시그널링 패킷의 흐름을 관리하는 기능들을 적어도 포함할 수 있다.
-멀티라디오 컨트롤러(Multiradio Controller, MRC): 멀티라디오 컨트롤러는 통합 라디오 어플리케이션을 동시에 실행시키는 것에 의해서 무선 자원들에 대한 요청을 스케쥴링하고 동시에 실행된 통합 라디오 어플리케이션들 간의 상호 작용성 문제들을 검출하고 관리하기 위한 기능들을 적어도 포함할 수 있다. 또한, 분산된 컴퓨팅이 적용될 경우, 멀티 라디오 컨트롤러는 스펙트럼 자원 사용 상태를 보고하는 기능을 포함할 수 있다.
-리소스 매니저(Resource Manager, RM): 리소스 매니저는 연산 자원들을 관리하고, 동시에 활성화된 통합 어플리케이션들 간에 연산 자원들을 공유하며, 그들의 리얼 타임 실행을 보장하기 위한 기능들을 적어도 지원할 수 있다. 또한, 분산된 컴퓨팅이 적용될 경우, 리소스 매니저는 컴퓨팅 자원의 사용 상태를 보고하는 기능을 포함할 수 있다.
라디오 컴퓨터에 의해서 제공되는 기능성(functionalities)를 표현하는 라디오 컨트롤 프레임워크는 모든 라디오 어플리케이션들이 공통된 재설정, 멀티라디오 실행 및 자원 공유 전략 프레임워크를 공유하는 것을 요구할 수 있다. 재구성 가능한 라디오 장치의 관점에서 모든 라디오 어플리케이션들이 공통적인 행동 방식(common behavior)을 가지기 때문에 라디오 어플리케이션들이 통합 라디오 어플리케이션(unified radio application, URA)로 지칭될 수 있다. 활성화/비활성화, 피어 장치 발견, 및 사용자 데이터 플로우를 통한 통신의 유지 등과 관련된 서비스들은 URA와 RCF 간의 인터페이스인 URAI를 통해서 제공될 수 있다.
도 3은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 멀티라디오 어플리케이션들을 설명하기 위한 개념도이다.
도 3을 참조하면, 재구성 가능한 라디오 장치는 적어도 하나의 라디오 컴퓨터(120, 130, 140)를 포함할 수 있다. 컴퓨팅 자원들(computational resources)의 동작은 주어진 운영 체제에 의해서 수행될 수 있으며, 바람직하게는 논-리얼 타임(non-real time) 기반으로 수행될 수 있다. 반면, 라디오 컴퓨터들의 동작은 통합 라디오 어플리케이션의 리얼 타임 동작들을 지원하는 별도의 운영 체제에 의해서 수행될 수 있다. 라디오 컴퓨터의 운영 체제를 라디오 OS(radio OS, ROS)라 지칭할 수 있고, 각각의 라디오 컴퓨터에 속할 수 있다.
컴퓨팅 자원들은 다음의 구성요소들을 포함할 수 있다.
-앞서 설명된 통신 서비스 계층의 부분들인 관리자, 이동성 정책 매니저, 네트워킹 스택 및 모니터의 실행을 위한 논-리얼 타임 OS. 멀티라디오 어플리케이션들을 위해서 OS는 라디오 컨트롤 프레임워크의 컴퓨팅 자원 부분(computational resources part)를 포함할 수 있다.
-모니터로 컨텍스트 정보를 전송하고 네트워킹 스택으로/부터 데이터를 전송/수신할 수 있는 라디오 어플리케이션 내의 라디오 컨트롤러(Radio Controller, RC)
라디오 컴퓨터(들)은 다음의 구성요소들을 포함할 수 있다.
-리얼 타임(real-time) OS인 라디오 OS
-라디오 컨트롤 프레임워크의 5가지 구성요소들. 라디오 컨트롤 프레임워크의 다섯 가지 구성요소들은 리얼 타임 실행과 관련된 그룹과 논-리얼 타임 실행과 관련된 그룹으로 분류될 수 있다. 어느 구성요소들이 리얼 타임 실행 및 논-리얼 타임 실행과 관련된 것인지는 벤더별로 달라질 수 있다.
도 4는 본 발명의 실시예들에 따른 라디오 컴퓨터의 시스템 아키텍처의 일 예를 설명하기 위한 개념도이며, 도 5는 본 발명의 실시예들에 따른 라디오 컴퓨터의 시스템 아키텍처의 다른 예를 설명하기 위한 개념도이다.
도 4와 도 5를 비교하면, 도 4의 실시예에서는 백-엔드 컴파일러(back-end compiler)가 각각의 라디오 컴퓨터에 존재하고 있다. 그러나, 도 5의 실시예에서는 백-엔드 컴파일러는 클라우드(cloud) 상에 존재하고 있다. 백-엔드 컴파일러의 성능 관리 및 업데이트를 적절하게 지원하기 위해서 백-엔드 컴파일러는 각각의 라디오 컴퓨터 상에 존재하는 것보다는 클라우드 상에서 관리될 수 있다.
라디오 컴퓨터는 재구성 가능한 라디오 장치를 위해서 통신 능력을 제공하며, 재구성 가능한 라디오 장치의 유형에 따라서 아래 구성요소들을 포함할 수 있다.
-라디오 컨트롤 프레임워크를 포함한 라디오 OS
-실행 가능 코드(executable code), 소스코드 또는 IR 코드인 통합 라디오 어플리케이션 설정 코드(configcodes)
-라디오 가상 머신(RVM)
- 통합 라디오 어플리케이션 설정 코드가 재구성 장치 내에서 컴파일되거나 통합 라디오 어플리케이션 설정 코드가 다이나믹 링킹(dynamic linking)으로 클라우드에서 컴파일되는 경우, 라디오 라이브러리 네이티브 구현(native implementation)
-라디오 플랫폼
통합 라디오 어플리케이션 설정 코드는 실행 코드(executable code)이거나 라디오 가상 머신에 의해서 해석될 수 있다.
프론트-엔드 컴파일러가 타겟 플랫폼을 위한 실행 코드를 생성할 수 있고, 설정 코드는 타겟 플랫폼의 실행 코드와 동등할 수 있다. 이 경우, 도 4에 도시된 라디오 라이브러리 네이티브 구현 및 백-엔드 컴파일러는 라디오 컴퓨터에서 요구되지 않는다.
라디오 가상 머신은 설정 코드를 실행할 수 있는 추상화 머신으로 하드웨어에 비의존적이다. 라디오 가상 머신의 구현은 타겟 라디오 컴퓨터 특정적이며, 설정 코드를 실행 가능한 코드로 컴파일하기 위한 Just-in-Time (JIT) or Ahead-of-Time (AOT) 방법을 제공하는 백-엔드 컴파일러를 포함할 수 있다.
통합 라디오 어플리케이션 설정 코드는 소스 코드이거나 IR 코드인 경우, 백-엔드 컴파일러는 아래 2가지 방식으로 구현될 수 있다. 즉, 주어진 라디오 장치 내에서 통합 라디오 어플리케이션이 컴파일되거나, 클라우드 상에서 통합 라디오 어플리케이션이 컴파일될 수 있다.
전자의 경우, 도 4에서 보여지는 바와 같이, 라디오 라이브러리 네이티브 구현과 백-엔드 컴파일러는 라디오 컴퓨터 내에 존재할 수 있다. 따라서, 이 경우, 통합 라디오 어플리케이션 설정 코드는 라디오 컴퓨터에 소스 코드 또는 IR의 형태로 다운로드될 수 있고, 라디오 컴퓨터 내의 백-엔드 컴파일러를 통해서 대응되는 실행 가능 코드로 변환된다. 이 경우, 백-엔드 컴파일러는 라디오 가상 머신의 일부일 수 있다.
후자의 경우, 도 5에서 보여지는 바와 같이, 컴파일 과정은 라디오 컴퓨터가 아닌 클라우드(510)에서 수행될 수 있다. 따라서, 통합 라디오 어플리케이션 설정 코드는 라디오는 클라우드에서 컴파일된 결과물인 실행 가능한 코드의 형태로 라디오 컴퓨터에 다운로드된다. 이 경우, 플랫폼 벤더는 자신의 라디오 플랫폼에 따른 백-엔드 컴파일러 및/또는 라디오 라이브러리 네이티브 구현을 클라우드에 제공해야 한다.
한편, 라디오 라이브러리 네이티브 구현은 후술될 스태틱/다이나믹 링킹의 경우에 클라우드 또는 라디오 장치에 제공되어야 한다. 라디오 라이브러리는 SFB들로 구성될 수 있다. 하나의 라디오 어플리케이션은 상호 연결된 SFB들과 UDFB들의 집합으로 표현될 수 있다. 라디오 라이브러리의 표준적 기술(normative description)로부터 제공되는 SFB들은 플랫폼-비의존적인 표준적 언어(normative language)로 표현될 수 있다. 라디오 라이브러리 네이티브 구현은 타겟 플랫폼을 위한 라이브러리로부터 SFB들의 플랫폼-특정적인 코드들로 제공될 수 있다. 라디오 라이브러리는 확장 가능하다(extendable).
도 4 및 도 5에서, 라디오 어플리케이션 스토어(RadioApp store)는 라디오 프로그래밍 인터페이스(Radio Programming Interface, RPI)를 가질 수 있다.
통합 라디오 어플리케이션의 배포 및 설치
재구성 가능한 라디오 장치에 탑재되는 라디오 어플리케이션들을 통합 라디오 어플리케이션들(unified radio application, URA)로 지칭할 수 있다. 통합 라디오 어플리케이션들을 배포하고 실행하는 과정은 디자인 단계(design time), 설치 단계(installation time), 실행 단계(run time)의 3 단계로 구성될 수 있다.
도 6 내지 도 10은 본 발명의 실시예들에 따른 통합 라디오 어플리케이션의 배포/실행 과정을 설명하기 위한 개념도들이다.
도 6 내지 도 10은 플랫폼-특정적 실행 가능 코드 형태의 라디오 어플리케이션을 배포/실행하는 과정, 플랫폼-비의존적인 소스 코드 형태의 라디오 어플리케이션을 배포/실행하는 과정, 및 플랫폼-비의존적인 IR 코드 형태의 라디오 어플리케이션을 배포/실행하는 과정을 설명하고 있다.
디자인 단계에서, 라디오 어플리케이션 코드 제공자는 라디오 어플리케이션 패키지(Radio Application Package, RAP)를 생성할 수 있다. RAP는 파이프라인 설정을 위한 메타 데이터 및 라디오 어플리케이션 코드들을 포함할 수 있다. 라디오 컨트롤러 코드는 라디오 어플리케이션 코드의 일부이다. 라디오 컨트롤러 코드가 논-리얼 타임 환경에서 실행될 경우, 해당 라디오 컨트롤러 코드는 RAP에 포함되기 전에 주어진 컴퓨팅 자원에서 실행되도록 컴파일될 수 있다.
설치 단계에서 RAP는 라디오 앱스토어(RadioApp Store)로부터 다운로드되고 재구성 가능한 라디오 장치에 설치될 수 있다. RAP에 포함된 라디오 컨트롤러 코드를 포함한 라디오 어플리케이션 코드 및 메타데이터(예컨대, 파이프라인 구성을 위한)는 재구성 가능한 라디오 장치에 설치될 수 있다. SFB 및 UDFB들과 같은 기능 블록들은 리얼 타임으로 처리되기 위해서 라디오 컴퓨터에 설치되어야 하지만, 컨텍스트 정보 처리와 같은 리얼 타임 처리가 반드시 필요하지 않은 동작들을 위한, 논-리얼 타임 영역에서 동작하는 라디오 컨트롤러 코드는 컴퓨팅 자원에 설치될 수 있다.
도 6을 참조하면, 주어진 재구성 가능한 라디오 장치에서 실행 가능한 설정 코드들이 배포되는 경우가 도시되어 있다. 설정 코드가 실행 가능한 경우, 기능 블록들(SFB들 및 UDFB들)은 라디오 컴퓨터 상에서 실행된다. 대응되는 설정코드를 생성하기 위해서 기능 블록들은 각 타겟 플랫폼을 위해서 디자인 단계에서 컴파일된다. 즉, SFB들과 UDFB들은 주어진 라디오 컴퓨터에 따라서 미리 컴파일되어 디자인 타임에서 RAP에 포함된다. 컴파일 이후에 UDFB들 및 SFB들을 포함한 설정 코드들은 라디오 OS에서 동작되기 위해서 재구성 가능한 라디오 장치에 설치되고 로드될 수 있다.
도 7 및 도 8을 참조하면, 설정 코드가 스태틱 링킹 및 다이나믹 링킹을 위해서 플랫폼-비의존적 소스 코드의 형태로 설정 코드가 배포되는 경우가 각각 도시되어 있다. 설정 코드가 플랫폼-비의존적인 소스 코드의 형태로 제공될 경우, 라디오 어플리케이션 코드는 라디오 컨트롤러 코드와 UDFB 코드들만을 포함할 수 있다. SFB들의 경우, 메타데이터가 효율적인 컴파일을 위한 정보를 제공할 수 있다. 타겟 통합 라디오 어플리케이션의 실행을 위해서 필요한 SFB들의 함수 호출(function calls)들은 설정 코드에 포함될 수 있다. UDFB들로 구성된 설정 코드는 설치 단계에서 재구성 가능한 라디오 장치 또는 클라우드에서 컴파일 된다. SFB들의 네이티브 구현은 실행 단계 이전에 완료되고 네이티브 라이브러리에 포함된다.
도 7은 스태틱 링킹(static linking)의 경우로, UDFB들과 SFB들의 링킹은 설치 단계에서 수행될 수 있다. 실행 단계에서 컴파일된 코드들은 ROS 상에서 수행될 수 있도록 로드될 수 있다. 도 8은 다이나믹 링크(dynamic linking)의 경우, UDFB들과 SFB들의 링킹은 실행 단계에서 수행될 수 있다.
도 7 및 도 8에서 보여지는 바와 같이, 라디오 어플리케이션 코드는 선택적으로 암호화(encrypted)될 수 있다. 라디오 어플리케이션 코드가 암호화된 경우, 대응되는 설정 코드는 설치 단계에서 컴파일 이전에 복호화(decrypted)되어야 한다.
도 9 및 도 10을 참조하면, 스태틱 링킹 및 다이나믹 링킹을 위해서 플랫폼-비의존적인 IR의 형태로 설정 코드가 배포되는 경우를 도시하고 있다. 플랫폼-비의존적인 IR의 형태로 설정 코드가 제공될 경우, UDFB들을 포함한 라디오 어플리케이션 설정 코드들은 디자인 단계에서 프론트-엔드 컴파일될 수 있다. 프론트-엔드 컴파일된 설정 코드들은 설치 단계에서 재구성 가능한 라디오 장치에서 백-엔드 컴파일되어 주어진 라디오 컴퓨터에 특정적인 실행 가능 코드로 변환될 수 있다. SFB들의 네이티브 구현은 실행 단계 전에 완료되어 네이티브 라이브러리에 포함될 수 있다.
도 9는 스태틱 링킹(static linking)의 경우로, UDFB들과 SFB들의 링킹은 설치 단계에서 수행될 수 있다. 실행 단계에서, 백-엔드 컴파일된 코드들이 ROS 상에서 수행될 수 있도록 로드될 수 있다. 도 10은 다이나믹 링크(dynamic linking)의 경우, UDFB들과 SFB들의 링킹은 실행 단계에서 수행될 수 있다.
통합 라디오 어플리케이션의 동작 구조
실행 단계에서 통합 라디오 어플리케이션의 동작 구조(operational structure)가 설명된다. 설명의 단순화를 위해서, 이하에서는 라디오 장치가 하나의 라디오 컴퓨터를 구비한 경우를 가정한다. 즉, 라디오 장치 내의 각 라디오 컴퓨터에는 동일한 동작 구조가 적용될 수 있다. 아래의 2가지 경우가 고려된다.
-통합 라디오 어플리케이션 설정 코드가 주어진 라디오 장치에서 실행 가능한 코드인 경우
-통합 라디오 어플리케이션 설정 코드가 주어진 라디오 장치에서 컴파일되어야 하는 소스 코드 또는 IR인 경우
도 11 내지 도 13은 본 발명의 실시예들에 따른 통합 라디오 어플리케이션의 동작 구조를 설명하기 위한 개념도들이다.
SFB들은 2개의 그룹들로 분류될 수 있다. 즉, 하나의 그룹은 전용 하드웨어 가속기(dedicated hardware accelerator)를 필요로 하는 SFB 들의 그룹이며, 다른 하나의 그룹은 전용 하드웨어 가속기를 필요로 하지 않는 SFB들의 그룹이다. 전용 하드웨어 가속기가 이용될 경우, 하드웨어 가속기는 라디오 HAL을 통해서 액세스될 수 있다. 다른 경우, 플랫폼 특정적인 코드가 라디오 라이브러리에 의해서 관련된 SFB를 위해서 제공된다.
도 11을 참조하면, 통합 라디오 어플리케이션 설정 코드가 주어진 라디오 장치에서 실행 가능한 코드로 주어지는 경우의 통합 라디오 어플리케이션의 동작 구조가 도시되어 있다. 이 경우, 주어진 통합 라디오 어플리케이션을 수행하기 위해서 필요한 SFB들과 UDFB들은 이미 통합 라디오 어플리케이션의 실행 가능한 설정 코드에 포함되어 있다.
도 12를 참조하면, 통합 라디오 어플리케이션 설정 코드가 주어진 라디오 장치에서 컴파일되어야 하는 소스 코드 또는 IR인 경우의 통합 라디오 어플리케이션의 동작 구조가 도시되어 있다. 이 경우, 주어진 통합 라디오 어플리케이션을 수행하기 위해서 필요한 UDFB들(45)은 통합 라디오 어플리케이션의 설정 코드에 포함되며, 컴파일러(소스 코드인 경우) 또는 백-엔드 컴파일러(IR인 경우)에 의해서 컴파일된다. 한편, 라디오 라이브러리 네이티브 구현은 통합 라디오 어플리케이션 설정 코드에 포함될 수 없기 때문에 주어진 라디오 장치 내에 별도로 준비되어야 한다. 앞서 언급된 바와 같이, SFB들의 함수 호출들(function call)은 메타 데이터에서 제공된다.
라디오 라이브러리는 라디오 컴퓨터 상에서 구현되는 SFB들을 포함하기 때문에 라디오 라이브러리 네이티브 구현은 라디오 컴퓨터 벤더에 의해서 제공된다. SFB들은 하드웨어 가속기를 이용하지 않고 구현될 수도 있고, 하드웨어 가속기와 프로그램 코드를 결합하여 다른 SFB들을 생성하기 위해서 구현될 수도 있다.
도 13을 참조하면, 상술된 2가지 경우의 하이브리드(hybrid) 동작 구조가 도시되어 있다. 즉, 통합 라디오 어플리케이션은 실행 가능 코드와 IR 코드를 이용하여 구성될 수 있다. 이 경우의 실행 가능 코드의 동작 절차는 도 11에 개시된 경우와 동일하다. 통합 라디오 어플리케이션의 IR 부분은 라디오 가상 머신에서 처리될 수 있다. 이러한 방식으로, IR 부분은 실행 단계에서 실행될 수 있다. 라디오 가상 머신은 인터프리터로서 예를 들면 just-in-time 컴파일러 등으로 구현될 수 있다.
상술된 3가지의 경우에서, 라디오 HAL은 하드웨어 가속기를 이용한 SFB들의 구현을 위한 하드웨어 추상화를 포함한다. 이는 하드웨어 가속기(들)을 이용하여 구현되는 SFB들이 주어진 통합 라디오 어플리케이션 코드에 의해서 호출될 때마다, 라디오 HAL을 통하여 대응되는 하드웨어 가속기 상에서 직접 구현되어야 함을 의미한다. 후술되는 바와 같이, 라디오 HAL은 또한 적어도 하나가 하드웨어 가속기를 이용하여 구현되는 SFB들의 집합으로 구성된 UDFB들에 대한 하드웨어 추상화를 포함하여야 한다.
SFB들은 많은 라디오 어플리케이션들에서 공통적으로 사용되는 기능 블록들-예컨대, FFT(Fast Fourier Transform)- 및/또는 주어진 라디오 플랫폼에서 특수 목적 가속기를 사용하여 매우 효율적으로 구현되어야만 하는 어떠한 기능 블록들-예컨대, 터보 코더-이 될 수 있다. 따라서, SFB들은 소프트웨어 또는 전용 하드웨어로 구현될 수 있다.
한편, 도 12에서 보여진 '사용자 기능 블록 집합(UDFB set)'은 주어진 라디오 어플리케이션(들)에 의해서 사용되는 UDFB들을 포함한다. 어떠한 SFB라도 그것을 적절한 UDFB로 대체하는 것에 의해서 수정 및/또는 확장 가능하다는 점이 중요하다. 따라서, UDFB들은 SFB들의 확장을 위해서 좋은 후보가 될 수 있으며, 그것들이 추후 SFB으로서 추가될 수 있음을 의미한다. 이러한 경우에, UDFB들이 SFB으로서 추가된 후에는 정규(normal) SFB들로서 규정될 것이다. '사용자 기능 블록 집합(UDFB set)'은 라디오 플랫폼 벤더 대신 라디오 어플리케이션의 제공자(즉, 3rd party)에 의해서 제공될 수 있기 때문에, 라디오 컨트롤 프레임워크가 모든 UDFB의 이벤트 및/또는 커맨드들의 기본적인 제어를 수행할 수 있도록 하기 위해서, 'start', 'stop', 'pause', 'get port' 및 'initialize'와 같은 제어 인터페이스들의 표준 집합이 대응되는 UDFB들을 위해서 규정되어야만 할 수 있다.
도 11 내지 도 13의 통합 라디오 어플리케이션의 동작 구조는 아래와 같은 구성요소들을 포함할 수 있다.
-통합 라디오 어플리케이션은 주어진 RAP의 메타 데이터의 내용에 따른 SFB(들)과 UDFB(들)을 포함할 수 있다.
-라디오 라이브러리는 라디오 컴퓨터 상에서 구현되는 SFB들의 플랫폼-특정적 코드를 포함할 수 있다. 하드웨어 가속기를 이용하여 구현되는 SFB들은 라디오 HAL을 통해서 지원된다. 이러한 경우, 라디오 라이브러리는 일반적으로 하드웨어 가속기(들)을 액세스할 수 있는 함수 호출(function call)을 포함할 수 있다.
-사용자 정의 기능 블록 집합(UDFB set)은 주어진 통합 라디오 어플리케이션에 의해서 이용되는 모든 UDFB들을 포함할 수 있고, 일반적으로 라디오 어플리케이션 제공자에 의해서 제공될 수 있다. UDFB들은 RAP에 메타 데이터(metadata) 및 라디오 컨트롤러 코드와 함께 포함된다. 일반적으로 UDFB는 SFB의 수정 및/또는 확장 버전이기 때문에, UDFB은 SFB들에 대해서 의존성을 가질 수 있다.
- 라디오 HAL은 라디오 플랫폼을 추상화한다. 라디오 HAL은 SFB들이 대응되는 전용 하드웨어 가속기(들) 상에서 직접 실행될 수 있도록 전용의 하드웨어 가속기를 이용하여 구현되는 SFB들을 지원한다.
- 라디오 플랫폼 드라이버는 라디오 OS가 라디오 플랫폼을 액세스하기 위해서 이용하는 하드웨어 드라이버이다.
- 라디오 플랫폼은 일반적으로 RF 송수신기, 안테나, 고정 및/또는 설정가능한 하드웨어 가속기(들), 및/또는 프로그래머블 IP 코어(들)을 모두 포함하여 구성될 수 있다.
도 14는 본 발명의 실시예들에 따른 라디오 컴퓨터 상에서의 기능 블록들을 구현을 설명하기 위한 개념도이다.
도 14를 참조하면, 프로그래머블 구성요소들을 위한 SFB들의 숫자는 M1이며, 전용의 하드웨어 가속기를 요구하는 SFB들의 숫자는 M2일 수 있다. 따라서, 전체 SFB들의 숫자 M은 M1+M2일 수 있다. 앞서 언급된 것과 같이, 일부 SFB들(예컨대, FFT, 터보 디코더, MIMO 디코더, 등)은 높은 성능과 저전력 소모를 위해서 대응되는 하드웨어 가속기 상에서 직접 구현될 수 있다. 이러한 하드웨어 가속기에 의해서 실행되는 이러한 SFB들은 대응되는 전용 가속기 상의 구현을 위해서 라디오 HAL에 의해서 지원된다. 이는, 전용 가속기 상에서 구현되는 각 SFB가 통합 라디오 어플리케이션에서 호출되는 경우, 라디오 HAL을 통해서 대응되는 전용의 가속기 상에서 직접 구현되어야 함을 의미한다. 유사하게, 예를 들어 bit-reverse, multiply 및 accumulation 등의 SFB들에 의해서 제공되는 동작들은 프로그래머블 구성요소에서 구현될 수 있다.
결과적으로, 라디오 컴퓨터 상에서 필요한 SFB/UDFB 실행 코드들은 다음 두 부분으로 구성된다. 하나의 부분은 프로그래머블 구성요소들 상에서 수행되는 실행코드이며, 다른 부분은 전용 가속기들 상에서 수행되는 라디오 HAL 코드들이다.
이는 다음과 같이 요약될 수 있다. {C: SFB/UDFB들의 구현을 위해 필요한 라디오 컴퓨터 상의 실행 코드들}={A: 프로그래머블 구성요소들 상에서 수행되는 SFB/UDFB들을 위한 실행 코드들}+{B: 전용의 하드웨어 가속기들 요구하는 SFB/UDFB들을 위한 라디오 HAL 코드들}. 즉, C=A+B이며 A와 B의 분할은 각 벤더들에 의해서 결정될 수 있다.
이는 또한 다음을 암시한다. {SFB/UDFB들}={프로그래머블 구성요소 상에서 구현되는 SFB/UDFB들}과 {전용 하드웨어 가속기들 상에서 구현되는 SFB/UDFB들}의 합집합이며, {프로그래머블 구성요소 상에서 구현되는 SFB/UDFB들}과 {전용 하드웨어 가속기를 요구하는 SFB/UDFB들}의 교집합은 공집합이 된다.
SFB들을 두 그룹-즉, 전용 하드웨어 가속기를 필요로 하는 그룹과, 전용 하드웨어 가속기를 필요로 하지 않는 그룹-으로 분류한 이유는 각 카테고리가 나름의 장점과 단점을 가지고 있기 때문이다. 전자는 일반적으로 전용의 하드웨어 로직으로 구현되므로, 전력 소모, 속도가 필요한 동작 및 아마도 비용 효율성에서 유리하다. 반면, 후자는 일반적으로 마이크로프로세서 상에서 수행되기 때문에 유연성(flexibility)에서 유리하다. 성능의 측면에서 프로그래머블 구성요소들이 전용의 하드웨어 가속기들에 비하여 경쟁력을 가질 때까지는 초기 단계에서는 전용의 하드웨어 가속기들이 상대적으로 더 광범위하게 사용될 것이 예상된다. 반도체 기술이 점점 더 진화할수록, 프로그래머블 구성요소를 위한 SFB들이 점진적으로 더 우세해 질것이다.
한편, 여러 개의 베이스밴드유닛(BBU, Baseband Unit)으로 구성되어 있는 클라우드 무선 접속 네트워크(Cloud Radio Access Network) 상황에서, 각 베이스밴드 유닛은 하나의 라디오 컴퓨터로 볼 수 있다. 기존 클라우드 무선 접속 네트워크의 각 베이스밴드유닛은 LTE 라디오 어플리케이션을 실행함으로써 각 베이스밴드 유닛이 LTE 기지국 역할을 하였다. 5G NR이 출현함에 따라 LTE 기지국에서 5G NR 기지국 역할을 수행하기 위해 5G NR 라디오 어플리케이션을 각 베이스밴드유닛에 다운로드 받아 실행시키려 하지만, 5G NR 라디오 어플리케이션에서 요구하는 라디오 컴퓨터 즉, 베이스밴드 유닛의 성능이 너무 높아 하나의 베이스밴드유닛에서 하나의 5G NR 라디오 어플리케이션을 실행시킬 수 없을 수 있다. 이때 본 발명에서 제안하는 5G NR 라디오 어플리케이션을 각 라디오 컴퓨터, 즉, 베이스밴드 유닛에 분산 설치하는 방법을 이용하여 라디오 어플리케이션을 분산 설치하여 실행시킬 수 있다.
또 다른 예로, 이미 클라우드 무선 접속 네트워크의 각 베이스밴드 유닛은 LTE 라디오 어플리케이션을 실행함으로써 LTE 기지국 역할을 하고 있는 상황에서, 남은 하드웨어 리소스를 활용하여 5G NR 라디오 어플리케이션을 실행하려고 하는 요구가 있을 수 있다. 이미 LTE 라디오 어플리케이션을 실행 중에 있기 때문에 남은 하드웨어 리소스가 많지 않아, 5G NR 라디오 어플리케이션 전체를 하나의 베이스밴드유닛에서 실행할 수 없을 수 있다. 이때 여러 베이스밴드에 5G NR 라디오 어플리케이션을 나누어 설치하여 실행함으로써 요구사항을 만족시킬 수 있다.
도 1을 다시 참조하면, 재구성 가능한 라디오 장치는 다종/다중 라디오 어플리케이션들을 동시에 실행할 수 있고 라디오 어플리케이션 패키지(Radio Application Package, RAP)에 의해 라디오 컴퓨터들의 설정을 변경할 수 있다. 모든 라디오 어플리케이션들(RAs)은 라디오 장치의 라디오 재구성과 관련된 요구사항의 관점에서 공통 속성이나 특성을 나타낼 때 통합 라디오 어플리케이션(Unified Radio Applications, URAs)으로 지칭될 수 있다.
다종/다중 통합 라디오 어플리케이션을 실행하기 위하여, 앞서 설명된 바와 같이, 재구성 가능한 라디오 장치는 통신 서비스 계층(Communication Services Layer, CSL), 라디오 컨트롤 프레임워크(Radio Control Framework, RCF), 라디오 플랫폼(Radio Platform) 및 이들의 상호 연결을 위한 4 세트의 인터페이스들을 포함할 수 있다.
무선 기기 아키텍처(Mobile Device Architecture)는 일반화된 멀티라디오 인터페이스(generalized MUltiRadio Interface, gMURI), 일반화된 재구성 가능한 RF 인터페이스(generalized Reconfigurable Radio Frequency Interface, gRRFI), 일반화된 통합 라디오 어플리케이션 인터페이스(generalized Unified Radio Application Interface, gURAI), 및 일반화된 라디오 프로그래밍 인터페이스(generalized Radio Rrogramming Interface, gRPI)를 포함하는 4 세트의 인터페이스들을 포함할 수 있다.
gMURI는 통신 서비스 계층과 라디오 컨트롤 프레임워크의 인터페이스이다. gRRFI는 통합 라디오 어플리케이션과 RF 송수신기(RF transceiver)의 인터페이스이다. gURAI는 통합 라디오 어플리케이션과 라디오 컨트롤 프레임워크의 인터페이스이다. 그리고 gRPI는 라디오 어플리케이션의 독립적이고 균일한 생산을 위한 인터페이스이다.
도 15는 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 인터페이스들의 UML(Unified Modeling Language) 클래스 블록도이다.
통합 모델링 언어(Unified Modeling Language, UML)을 이용하여 gRRFI, gMURI, gURAI, 및 gRPI 등과 관련된 정보 모델(information model)과 프로토콜을 정의할 수 있으나, 이에 한정되지는 않으며, 다른 모델링 언어도 사용될 수 있다.
도 15를 참조하면, 재구성 가능한 라디오 장치는 개개의 통합 라디오 어플리케이션들이 소정의 소프트웨어 엔티티들로서 설계될 때 라디오 컴퓨터(Radio Computer)의 집합체를 포함할 수 있다.
전술한 경우, 라디오 컴퓨터 클래스(RadioComputer)는 gMURI에 연결되는 라디오 컴퓨터 인터페이스의 UML 클래스(IgMURI), gRRFI에 연결되는 라디오 컴퓨터 인터페이스의 UML 클래스(IgRRFI), gURAI에 연결되는 라디오 컴퓨터 인터페이스의 UML 클래스(IgURAI), 및 gRPI에 관련된 라디오 컴퓨터 인터페이스의 UML 클래스(IgRPI)를 포함할 수 있다.
도 16은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치에서 gMURI를 이용하는 통신 서비스 계층(CSL)과 라디오 컨트롤 프레임워크(RCF) 간의 상호 접속을 설명하기 위한 개념도이다.
도 2에서 설명된 바와 같이, 재구성 가능한 라디오 장치가 복수의 라디오 컴퓨터들을 포함할 수 있으므로, gMURI들 사이에는 라우팅을 위한 엔티티가 존재할 수 있다. 라우팅 엔티티는 통신 서비스 계층과 라디오 컨트롤 프레임워크 사이의 시그널링에 대한 라우팅을 수행할 수 있고, 라디오 컴퓨터들 간에 교환되는 데이터에 대한 라우팅을 수행할 수 있다. 도 16은 통신 서비스 계층(CSL)과 라디오 컨트롤 프레임워크(RCF)가 일반화된 멀티라디오 인터페이스(gMURI)를 이용하여 어떻게 서로 상호 작용하는지는 나타낸다.
라우팅을 위한 엔티티는 TCP/IP 프로토콜을 사용하는 경우 상용 라우터 장비를 사용할 수 있고, TCP/IP 프로토콜을 사용하지 않고 이더넷 프로토콜만을 사용하는 경우 상용 스위치 장비가 될 수 있다. 라우팅을 위한 엔티티는 통신 서비스 계층이 각 라디오 컴퓨터에게 전달하고자 하는 명령을 통신 서비스 계층이 할당한 ID에 따라 해당 라디오 컴퓨터에 전달해준다. 이의 역과정으로 라우팅을 위한 엔티티는 라디오 컴퓨터들이 통신 서비스 계층에 전달하는 메시지를 통신 서비스 계층에 전달해준다.
도 16에 도시된 바와 같이, gMURI는 관리 서비스(Administrative Services), 접속 제어 서비스(Access Control Services) 및 데이터 흐름 서비스(Data Flow Services)의 3 종류의 서비스들을 지원할 수 있다.
관리 서비스(Administrative Services), 접속 제어 서비스(Access Control Services) 및 데이터 흐름 서비스(Data Flow Services) 중 적어도 하나 이상은 통신 서비스 계층(CSL)에 의해 제공될 수 있다. 라디오 컨트롤 프레임워크(RCF는 라디오 컴퓨터에서 동작하며 통신 서비스 계층(CSL)과 연동하여 통합 라디오 어플리케이션(Unified Radio Application)의 동작 환경을 제공할 수 있다. gMURI에서 지원하는 3종류의 서비스들을 좀더 구체적으로 설명하면 다음과 같다.
관리 서비스(Administrative Services)는 통신 서비스 계층에 포함되는 관리자(Adminstrator) 등의 일부 장치 구성 어플리케이션에 의해 사용된다. 관리자는 재구성 가능한 라디오 장치에 새로운 통합 라디오 어플리케이션을 설치하거나 제거할 수 있고, 통합 라디오 어플리케이션의 인스턴스(instance)를 생성하거나 제거할 수 있다. 설치(Installation) 및 로딩(loading)은 이용가능한 통합 라디오 어플리케이션을 재구성할 때 네트워크 접속을 설정하기 위한 장치 스타업 시간에서뿐만 아니라 실행 시간 동안에 실시될 수 있다. gMURI는 어떠한 가정 없이 언제 그리고 어떻게 라디오 장치에 대한 재구성이 필요한지 검출할 수 있다.
접속 제어 서비스(Access Control Services)는 이동성 정책 매니저(Mobility Policy Manager, MPM)에 의해 사용자 정책과 다른 무선 접속 기술(Radio Access Technologies, RATs)의 용도에 관련된 참조를 유지하고 이들 사이에서 선택하도록 사용된다. 이러한 참조와 선택 알고리즘의 모델링은 기본적으로 본 발명의 범위에 포함되지는 않으나, 일반화된 멀티라디오 인터페이스 사양은 통신 서비스 계층과 라디오 컨트롤 프레임워크 사이의 RAT 선택 결정의 정보 교환을 포함할 수 있다. 참조 자체는 어플리케이션들이나 최종 사용자 설정에서 국부적으로 생성될 수 있을 뿐 아니라 네트워크 운영자(network operator)나 인지 라디오 관리 프레임워크(cognitive radio management framework)로부터의 분배 방식으로 생성될 수 있다.
데이터 흐름 서비스(Data Flow Services)는 재구성 가능한 라디오 장치의 네트워크 스택(networking stack) 예컨대 TCP/IP(Transmission Control Protocol/Internet Protocol) 스택에 의해 사용된다. 따라서 데이터 흐름 서비스는 (논리) 링크 계층 서비스(link layer services)의 설정을 표현할 수 있고, 이것은 통합 라디오 어플리케이션의 활성화와 관계없이 제공될 수 있다.
도 17은 본 발명의 실시예들에 따른 재구성 가능한 라디오 장치의 아키텍처에서 라우팅 엔티티와 각 라디오 컴퓨터의 스위치(switch)를 설명하기 위한 개념도이다.
도 17을 참조하면, 각 라디오 컴퓨터에 존재하는 스위치(Switch)가 라디오 컴퓨터에서 실행되는 기능 블록의 결과를 내부 혹은 외부로 전달해주기 위해 라우팅을 위한 엔티티와 상호 작용할 수 있다. 이때, 상기 스위치는 상용 제품 또는 소프트웨어적으로 구현된 가상 스위치(vSwitch)일 수 있다. 라우팅을 위한 엔티티는 스위치로부터 스위치가 위치한 라디오 컴퓨터에서 실행된 기능 블록의 결과를 수신하고, 해당 결과를 수신하여야 할 라디오 컴퓨터로 해당 결과를 전달(forward)할 수 있다. 또한, 라우팅을 위한 엔티티는 통신 서비스 계층(CSL)과 라디오 컴퓨터 간에 데이터를 전달할 수 있다.
도 18은 본 발명의 일 실시예에 따른 라디오 어플리케이션 패키지의 파이프라인 구성 및 파이프라인 메타데이터 형식을 설명하기 위한 개념도이다.
도 18에서는, 라디오 어플리케이션 패키지(즉, RAP #1)가 두 개의 파이프라인 태스크(task)를 가지고 있다고 프로그래머가 지정한 경우가 가정된다. 라디오 어플리케이션 패키지의 파이프라인 메타데이터(1810)는 메타데이터 타입, 이름, 버전, 파이프라인 내 태스크 개수, 부모(Parent) 클래스, 칠드런(Children) 클래스 등의 정보를 포함하고 있다. 파이프라인 메타데이터(1810)는 칠드런(children) 클래스로서 파이프라인 태스크 1(1820)과 파이프라인 태스크 2(1830)를 가질 수 있다.
각각의 파이프라인 태스크 메타데이터(1820 또는 1830)는 메타데이터 타입, 이름, 버전, 기능 블록의 개수, 부모(Parent) 클래스, 칠드런(Children) 클래스 등의 정보를 포함할 수 있다. 예를 들면, 태스크 1의 메타데이터(1820)에는 기능 블록이 A1, B1, F1, L1이 있으므로 Children 클래스에는 4개의 기능 블록들이 있는 것을 확인할 수 있다. 예를 들면, 태스크 2의 메타데이터(1830)에는 기능 블록이 C1, D1, E1이 있으므로 Children 클래스에는 3개의 기능 블록들이 있는 것을 확인할 수 있다. Children 기능 블록 클래스는 각 기능 블록들의 순서, 각 기능 블록의 실행에 요구되는 소요 시간 및 스루풋 제약 시간 등의 정보, 인풋, 아웃풋 타입 등의 정보를 가질 수 있다.
각 라디오 컴퓨터는 계산 성능을 나타내는 일반적인 지표로써, 라디오 컴퓨터가 부동 소수점 연산을 지원할 때는 GFLOPS(Giga FLoting point Operations per Second)를, 고정 수수점 연산을 지원할 때는 GMACS(Giga Multiply-Accumulators per Second)를 제시해야한다. 이러한 지표는 기능 블록을 라디오 어플리케이션에 설치할 때, 기능 블록이 설치된 이후 실행될 수 있는지 여부를 판단하는 데 도움을 줄 수 있다.
통합 라디오 어플리케이션의 분산 설치
재구성 가능한 라디오 장치에서 하나의 라디오 어플리케이션이 복수의 라디오 컴퓨터들에서 분산적으로 실행될 수 있도록, 하나의 라디오 어플리케이션을 분산적으로 설치하는 방법은 아래의 단계들로 구성될 수 있다.
1) 라디오 어플리케이션 패키지 다운로드
재구성 가능한 라디오 장치는 설치의 대상이 되는 라디오 어플리케이션 패키지를 라디오 앱스토어로부터 다운로드할 수 있다. 전술된 바와 같이, 라디오 어플리케이션 패키지는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드로 구성될 수 있다. 라디오 어플리케이션 패키지는 재구성 가능한 라디오 장치 내의 저장매체에 저장될 수 있다. 예를 들면, 라디오 어플리케이션 패키지를 구성하는 기능블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드는 저장매체 내에 분리되어 저장될 수 있다.
2) 기능 블록들을 복수의 그룹으로 분할
통신 서비스 계층(CSL)의 관리자(administrator)는 라디오 어플리케이션을 구성하는 기능 블록을을 각각 하나의 라디오 컴퓨터에서 실행될 수 있는 그룹들로 분할할 수 있다. 또한, 관리자(administrator)는 각 라디오 컴퓨터를 위한 분할된 라디오 어플리케이션의 기능 블록들의 그룹에 대한 파이프라인 구성을 생성할 수 있다.
도 19는 본 발명의 일 실시예에 따른 라디오 어플리케이션 패키지의 구성 및 대상 라디오 어플리케이션의 파이프라인 구성을 설명하기 위한 개념도이다.
도 19를 참조하면, 라디오 어플리케이션 패키지(1910)는 설치 대상인 통합 라디오 어플리케이션을 구성하는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드를 포함할 수 있다.
통신 서비스 계층(CSL)의 관리자(administrator)는 라디오 어플리케이션 패키지(1910)의 파이프라인 구성 메타데이터를 참조하여, 설치 대상인 통합 라디오 어플리케이션의 파이프라인 구성(1920)을 확인할 수 있다. 도 18 및 도 19의 예를 참조하면, 설치 대상인 통합 라디오 어플리케이션은 크게 두 개의 파이프라인으로 구성되며, 각 파이프라인은 해당 파이프라인을 구성하는 기능 블록들이 function call 순서(task order)대로 나열되어 있다.
관리자는 설치 대상인 통합 라디오 어플리케이션을 구성하는 기능 블록들을 하나의 라디오 컴퓨터에서 설치될 수 있는 기능 블록들로 구성된 여러 개의 그룹으로 분할할 수 있다. 즉, 관리자는 통합 라디오 어플리케이션을 각 라디오 컴퓨터에서 실행되는 기능 블록들의 그룹들로 분할할 수 있다. 예컨대, 라디오 어플리케이션을 구성하는 기능 블록들은 라디오 컴퓨터 #1에서 실행되는 기능 블록들의 그룹과 라디오 컴퓨터 #2에서 실행되느 기능 블록들의 그룹으로 분할될 수 있다. 이하에서는 2개의 기능 블록 그룹들이 2개의 라디오 컴퓨터에 설치되는 예를 설명하고 있으나, 그룹들의 수와 라디오 컴퓨터들의 수는 이에 한정되지 않는다.
이때, 관리자는 아래와 같은 조건들 전부 또는 일부을 고려하여 기능 블록들을 그룹으로 분할할 수 있다.
i) 라디오 컴퓨터는 대응되는 그룹에 포함된 기능 블록들을 실행할 수 있는 능력이 있어야 한다. 이러한 기능 블록들의 실행 가능 여부는 아래의 측면들에서 고려될 수 있다.
i-1) 기능 블록의 계산 요구사항, 메모리 요구사항 등을 이용한 판단
도 20은 기능 블록의 구조를 설명하기 위한 개념도이다.
도 20을 참조하면, 기능 블록은 Name(Input, Output) 형태의 인터페이스로 표현되며, 여러 속성들(property)을 포함할 수 있다. 이러한 속성들 중에는 해당 기능 블록을 실행하기 위한 요구사항 속성 또한 포함될 수 있다. 예를 들어, 해당 기능 블록을 실행하기 위한 요구 사항은 아래와 같이 해당 기능 블록의 복잡도 또는 해당 기능 블록에서 요구되는 연산 속도 등의 지표로 표현될 수 있다.
- 기능 블록의 복잡도(complexity)를 나타내기 위한 예시로, 시간 복잡도(기능 블록의 수행 시간 분석 결과에 따른 연산 요구 사항) 및/또는 공간 복잡도(기능 블록의 메모리 사용량 분석 결과에 따른 메모리 요구 사항)를 점근적 표기법(asymptotic notation)으로 나타낼 수 있다. 어떠한 기능 블록의 복잡도를 따질 때, 주어지는 데이터의 길이나 기능 블록이 실행되는 플랫폼의 성능 등 다양한 요소에 의해 복잡도가 달라질 수 있기 때문에 기능 블록의 복잡도를 객관적으로 나타낼 수 있는 기준이 필요하다. 점근적 분석법은 주어진 데이터 크기를 기준으로 수행 시간 혹은 사용 공간이 얼마나 되는지 객관적으로 비교할 수 있는 기준을 제시해준다. 빅오, 오메가, 세타 등의 방법이 있으며, 각각 점근적 상한선, 점근적 하한선, 점근적 상한선과 점근적 하한선의 교집합을 나타낸다.
- 기능 블록에서 요구되는 연산 속도를 나타내는 지표로서 MIPS(millions of instructions per second), FLOPS(floating point operations per second), MACS(Multiply-Accumulator per Second) 등의 표기법이 사용될 수 있다.
기능 블록들의 속성에 있는 기능 블록들의 연산 및 메모리 요구사항을 토대로, CSL의 관리자는 각 라디오 컴퓨터의 계산 성능을 나타내는 일반적인 지표 (MIPS, FLOPS, MACS, etc)와 비교하여 기능 블록들의 설치 가능 여부를 따질 수 있다.
i-2) 라디오 컴퓨터 벤더가 제공하는 표준 기능 블록들의 실행 결과 표를 이용한 판단
CSL의 관리자는 각 라디오 컴퓨터 벤더가 제공한 표준 기능 블록들의 실행 결과 표(또는, '벤치마크 결과 표')를 참조하여, 해당 기능 블록을 대상 라디오 컴퓨터가 실행할 수 있는지 여부를 판단할 수 있다. 각 라디오 컴퓨터 벤더는 표준 기능 블록들의 실행 결과를 라디오 컨트롤 프레임워크 내의 Resource Manager와 통신 서비스 계층의 관리자(Administrator)에게 제공할 수 있다. 예컨대, 하기 표 1 은 특정 라디오 컴퓨터에서의 표준 기능 블록 별 실행 결과 표이다.
표준 기능 블록 하드웨어 가속기 프로그래밍 가능한 코어
FFT (FFT-point: 2048) 4 EAs (throughput: 100Mbps for each, execution time: 0.01ms for each) Throughput: 20MbpsExecution time:0.2msComputational resource utilization: 11%Memory usage: 2MB
Turbo decoder (K: 6144, # of codeblocks 16, # of iterations: 6) 3 EAs (throughput: 150Mbps for each, execution time: 0.03ms for each) Throughput: 12MbpsExecution time:0.5sComputational resource utilization: 11%Memory usage: 2MB
Scrambling (length: 60000) Execution time:0.02msComputational resource utilization: 3%Memory usage: 1MB
Modulation (length: 300000) Execution time:0.06msComputational resource utilization: 4%Memory usage: 3MB
따라서, 라디오 컴퓨터 벤더는 모든 표준 기능 블록들에 있어 자기 자신의 라디오 컴퓨터에서 실행했을 때의 벤치마크 결과를 표로써 제시해야 한다. 이러한 벤치마크 결과 표는 태그 등을 이용하여 데이터 구조를 명기하기 위해, 마크업 언어 예를 들어, SGML, TeX, SAMI나 이의 파생 언어로 표기될 수 있다. 각 표준 기능 블록마다 입력 파라미터가 다를 수 있는데, 입력 파라미터는 해당 표준 기능 블록에서 가장 많은 실행 시간을 소요하는 worst case 파라미터를 입력하게 된다. 예를 들어, LTE 터보 디코더를 실행함에 있어 실행 시간이 가장 길게 걸리는 경우는 코드블록의 길이 K가 6144일 때이다. 다른 예를 들자면, LTE에서 사용하는 FFT의 경우 LTE 최대 대역폭인 20MHz를 사용했을 때, 2048 포인트의 가장 복잡한 연산을 수행하게 되므로 worst case 파라미터로써 2048을 입력했을 때의 결과를 제시한다.
벤치마크 결과로 제시할 수 있는 결과는 스루풋, 실행 시간, 계산 리소스 사용량, 메모리 사용량 등이 있을 수 있다. 라디오 컴퓨터는 하드웨어 가속기만으로 구성되거나, 프로그래밍 가능한(programmable) 코어로만 구성되거나, 하드웨어 가속기와 프로그래밍 가능한 코어를 모두 가지고 있을 수 있다. 이때 라디오 컴퓨터 벤더는 표준 기능 블록을 실행시킬 수 있는 장치 (하드웨어 가속기 혹은 프로그래밍 가능한 코어)에서의 벤치마크 결과를 모두 제시해야 한다. 표준 기능 블록을 하드웨어 가속기에서 실행시킬 지, 프로그래밍 가능한 코어에서 실행시킬 지 여부는 관리자가 결정할 수 있다.
CSL의 관리자(administrator)는 라디오 컴퓨터 벤더가 제공한 벤치마크 결과 표를 기반으로 기능 블록들의 실행을 에뮬레이션(emulation) 해봄으로써 기능 블록들의 설치 가능 여부를 판단할 수 있다.
ii) 기능 블록들이 각 라디오 컴퓨터에 설치된 이후, 기능 블록의 결과를 다른 라디오 컴퓨터의 기능 블록에 전달해줘야 할 때 요구되는 스루풋(throughput)이 라디오 컴퓨터 간의 인터페이스 용량보다 커선 안된다.
도 18 및 도 19를 다시 참조하면, 태스크 1에 대응되는 기능 블록들(A1, B1, 쪋, L1)은 라디오 컴퓨터 #1에 설치되고, 태스크 2에 대응되는 기능 블록들(C1, D1, E1)은 라디오 컴퓨터 #2에 설치될 수 있다. 즉, 태스크 1에 대응되는 파이프라인이 라디오 컴퓨터 #1에 설치되고, 태스크 2에 대응되는 파이프라인이 라디오 컴퓨터 #2에 설치될 수 있다.
상술된 바와 같이 기능 블록들이 라디오 컴퓨터 #1 및 라디오 컴퓨터 #2에 분산 설치된 경우를 가정하면, 라디오 컴퓨터 #1에서의 기능 블록 A1의 실행 결과는 라디오 컴퓨터 #2의 기능 블록 C2에게 전달되어야 하고, 라디오 컴퓨터 #2에서의 기능 블록 E1의 실행 결과는 라디오 컴퓨터 #1의 기능 블록 L1으로 전달되어야 한다.
따라서, 라디오 어플리케이션 패키지를 구성하는 파이프라인 구성 메타데이터는 인접한 기능 블록들 간에 필요로 하는 데이터 트래픽 양과 컨트롤 트래픽 스루풋에 대한 정보를 포함할 수 있다. 만약 인접한 기능 블록들이 동일한 라디오 컴퓨터에 설치되어 있는 경우, 이러한 스루풋 요구사항는 고려될 필요가 없다. 하지만 하나의 라디오 컴퓨터에서 실행된 기능 블록의 실행 결과가 다른 라디오 컴퓨터의 기능 블록에 전달되어야 하는 경우 상기 스루풋 요구사항이 고려되어야 한다.
도 21a와 도 21b는 기능 블록들의 분할 지점에 따라서 요구되는 데이터 트래픽과 컨트롤 트래픽의 스루풋을 설명하기 위한 개념도이다.
도 21a와 도 21b을 참조하면, 송신 체인(transmit chain, 2110)을 구성하는 파이프 라인과 수신 체인(receive chain, 2120)을 구성하는 파이프 라인 상에서 분할 지점(split point)에 따라서 분할 지점 전후의 기능 블록들 간의 인터페이스에 요구되는 데이터 트래픽과 컨트롤 트래픽 스루풋이 도시되어 있다. 위의 예의 경우, 라디오 컴퓨터 #1과 라디오 컴퓨터 #2 사이의 인터페이스가 제공하는 스루풋과 기능 블록 간에 정보를 교환하기 위한 요구 스루풋을 비교함으로써, CSL의 관리자는 라디오 어플리케이션을 기능 블록 단위로 나누어 분산 설치할 수 있는지 여부를 판단할 수 있다.
한편, 기능 블록들뿐만 아니라 라디오 컨트롤러 코드의 설치 위치도 고려되어야 한다. 기능 블록의 경우 실시간 처리를 지원하기 위해 무조건 라디오 컴퓨터에 설치되어야 하지만 라디오 컨트롤러 코드의 경우 어플리케이션 프로세서에 설치할 수도 있으며, 라디오 컴퓨터에도 설치할 수 있다. 만약 분산 설치를 하지 않는다면, 라디오 컨트롤러 코드는 재구성 가능한 라디오 장치의 설치 내부 정책에 따라 어플리케이션 프로세서 부분에 설치될 수도 있고, 라디오 컴퓨터에 설치될 수도 있다.
하지만 분산 설치를 하는 경우에는 기능 블록의 경우 라디오 컴퓨터에만 설치되어야 한다. 복수개의 라디오 컴퓨터들 중에 어느 라디오 컴퓨터에 라디오 컨트롤러 코드를 설치할지 여부는 라디오 컨트롤러 코드가 참조하는 컨텍스트 정보에 따라 달라진다. 예를 들어, 라디오 컨트롤러 코드가 BLER(block error rate)이라는 컨텍스트 정보를 모니터에게 전해준다고 하면, BLER을 계산하기 바로 직전의 기능 블록이 설치된 라디오 컴퓨터에 설치될 수 있다. 또는, 라디오 컨트롤러 코드는 해당 라디오 어플리케이션의 기능 블록들이 가장 많이 설치된 라디오 컴퓨터에 설치될 수 있다. 또는, 파이프라인 구성 메타데이터가 지정하는 라디오 컴퓨터에 설치될 수 있다.
3) 관리자(administrator)는 라우팅을 위한 엔티티를 거쳐 각 라디오 컴퓨터에 설치 정보를 전달할 수 있다.
관리자는 설치 정보를 포함한 메시지를 라우팅을 위한 엔티티로 전달하고, 라우팅을 위한 엔티티는 해당 정보를 각 라디오 컴퓨터에 전달할 수 있다.
예를 들면, 관리자는 라디오 어플리케이션 패키지 식별자(ID), 라디오 컴퓨터 ID, 각 라디오 컴퓨터의 파이프라인 구성 정보, 및 각 라디오 컴퓨터에 설치되어야 할 기능 블록들의 ID의 설치 정보를 포함하는 InstallRAReq 시그널링을 라우팅을 위한 엔티티에 전달할 수 있다.
라우팅을 위한 엔티티는 InstallRAReq 시그널링에서의 라디오 어플리케이션 패키지 ID, 라디오 컴퓨터 ID 정보를 기반으로 상기 설치 정보를 해당 라디오 컴퓨터에 전달할 수 있다. 라디오 컴퓨터 내의 Configuration Manager는 InstallRAReq 시그널링을 라우팅을 위한 엔티티로부터 수신하고, 라디오 컴퓨터 내에서 기능 블록들의 설치를 수행할 수 있다.
이때 라디오 컨트롤러 코드를 특정 라디오 컴퓨터에 설치하기로 한 경우, CSL의 관리자는 상기 라우팅을 위한 엔티티를 거쳐 라디오 컨트롤러 코드를 상술된 라디오 컴퓨터에 전달할 수 있고, 라디오 컴퓨터 내의 Configuration Manager는 수신된 라디오 컨트롤러 코드를 설치할 수 있다.
4) 관리자(administrator)는 라디오 컴퓨터 ID 뿐만 아니라 기능 블록 ID 또한 포함한 ListRAReq 시그널을 라우팅을 위한 엔티티에 보낸다.
라우팅을 위한 엔티티는 ListRAReq 시그널을 라디오 컴퓨터 ID에 기반하여 해당 라디오 컴퓨터에 전달해 주게 된다. 라디오 컴퓨터 내의 Configuration Manager는 ListRAReq 시그널을 라우팅 엔티티를 통해 전달받으면 현재 설치되어 있는 기능 블록들 또는 라디오 어플리케이션들의 리스트를 관리자(administrator)에 넘겨주게 된다.
위 과정을 통해 관리자(administrator)는 어떤 라디오 컴퓨터에 어떤 기능 블록들이 설치되었는지에 대한 라디오 컴퓨터별 기능 블록 설치 리스트를 업데이트하게 된다.
본 발명에 따른 방법들은 다양한 컴퓨터 수단을 통해 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위해 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.
컴퓨터 판독 가능 매체의 예에는 롬, 램, 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함한다. 상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 적어도 하나의 소프트웨어 모듈로 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (18)

  1. 복수의 라디오 컴퓨터들, 통신 서비스 계층(communication service layer), 및 라우팅 엔티티(routing entity)를 포함한 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법으로서,
    상기 통신 서비스 계층의 관리자(administrator)가 상기 통합 라디오 어플리케이션의 라디오 어플리케이션 패키지를 다운로드하는 단계-상기 라디오 어플리케이션 패키지는 상기 통합 라디오 어플리케이션을 구성하는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드를 포함함;
    상기 관리자가 상기 파이프라인 구성 메타데이터를 참조하여 상기 기능 블록들을 상기 복수의 라디오 컴퓨터들 중 적어도 둘 이상의 라디오 컴퓨터들 각각에서 실행되는 그룹들로 분할하는 단계; 및
    상기 관리자가 상기 라우팅 엔티티를 거쳐 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는 단계를 포함하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  2. 청구항 1에 있어서,
    상기 통신 서비스 계층은 논-리얼 타임(non-real time) 운영체제 상(operating system)에서 동작하며, 상기 적어도 둘 이상의 라디오 컴퓨터 각각은 리얼 타임(real time) 운영체제인 라디오 운영체제(radio operating system)를 포함하며, 상기 통합 라디오 어플리케이션이 상기 적어도 둘 이상의 라디오 컴퓨터에서 동작하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  3. 청구항 2에 있어서,
    상기 적어도 둘 이상의 라디오 컴퓨터 각각은
    상기 통합 라디오 어플리케이션에 동작 환경을 제공하는 라디오 컨트롤 프레임워크(radio control framework, RCF);
    상기 라디오 운영체제(radio operation system); 및
    적어도 하나의 라디오 플랫폼을 포함하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  4. 청구항 1에 있어서,
    상기 통신 서비스 계층은 상기 관리자(administrator), 이동성 정책 매니저(mobility policy manager), 네트워킹 스택(networking stack), 및 모니터(monitor)를 포함하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  5. 청구항 1에 있어서,
    상기 관리자는 상기 통합 라디오 어플리케이션의 상기 적어도 둘 이상의 라디오 컴퓨터에 대한 설치(installation) 또는 제거(uninstallation) 및 상기 상기 통합 라디오 어플리케이션의 인스턴스의 생성 또는 삭제를 수행하는 구성요소인,
    통합 라디오 어플리케이션의 분산 설치 방법.
  6. 청구항 1에 있어서,
    상기 기능 블록들을 상기 그룹들로 분할하는 단계에서, 상기 관리자는 상기 기능 블록들 각각을 실행하기 위한 요구 사항, 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과, 및 상기 기능 블록들 간의 데이터 트래픽 및 컨트롤 트래픽에 대해 요구되는 쓰루풋(throughput) 중 적어도 하나를 참조하여 상기 기능 블록들을 상기 그룹들로 분할하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  7. 청구항 6에 있어서,
    상기 기능 블록들 각각을 실행하기 위한 요구 사항은 점근적 표기법(asymptotic notation)으로 표기되는 상기 기능 블록들 각각의 연산 요구 사항 및/또는 메모리 요구 사항로 표현되는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  8. 청구항 6에 있어서,
    상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과는 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 벤더(vendor)로부터 수신되며, 상기 기능 블록들 중 적어도 일부에 대한 벤치마크 결과를 제공하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  9. 청구항 1에 있어서,
    상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는 단계에서, 상기 관리자는 상기 라디오 어플리케이션 패키지의 식별자(ID), 대상 라디오 컴퓨터의 ID, 상기 대상 라디오 컴퓨터의 파이프라인 구성 정보, 및 상기 대상 라디오 컴퓨터에 설치되는 기능 블록들의 ID를 포함한 정보를 상기 라우팅 엔티티를 거쳐서 상기 대상 라디오 컴퓨터에 전달하는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  10. 청구항 1에 있어서,
    상기 라디오 컨트롤러 코드는 논-리얼 타임 영역에서 동작하며 컨텍스트 정보(context information)를 처리하는 구성요소로서, 실행 가능한 코드(executablecode) 형태로 상기 라디오 어플리케이션 패키지에 포함되며, 상기 라디오 컨트롤러 코드는 상기 기능 블록들 중 상기 라디오 컨트롤러가 참조하는 컨텍스트 정보를 제공하는 기능 블록이 설치된 라디오 컴퓨터 또는 상기 통합 라디오 어플리케이션의 기능 블록들이 가장 많이 설치된 라디오 컴퓨터에 설치되는,
    통합 라디오 어플리케이션의 분산 설치 방법.
  11. 재구성 가능한 라디오 장치로서,
    복수의 라디오 컴퓨터들(radio computers);
    관리자(administrator), 이동성 정책 매니저(mobility policy manager), 네트워킹 스택(networking stack), 및 모니터(monitor)를 포함하는 통신 서비스 계층(communication service layer); 및
    상기 복수의 라디오 컴퓨터들과 상기 통신 서비스 계층 간의 통신을 수행하는 라우팅 엔티티(routing entity)를 포함하고,
    상기 관리자는 통합 라디오 어플리케이션을 구성하는 기능 블록들, 파이프라인 구성 메타데이터, 및 라디오 컨트롤러 코드를 포함한 라디오 어플리케이션 패키지를 다운로드하고, 상기 파이프라인 구성 메타데이터를 참조하여 상기 기능 블록들을 상기 복수의 라디오 컴퓨터들 중 적어도 둘 이상의 라디오 컴퓨터들 각각에서 실행되는 그룹들로 분할하고, 상기 관리자가 상기 라우팅 엔티티를 거쳐 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에 설치되는 상기 기능 블록들의 그룹에 대한 정보를 상기 적어도 둘 이상의 라디오 컴퓨터들 각각에게 전달하는,
    재구성 가능한 라디오 장치.
  12. 청구항 11에 있어서,
    상기 통신 서비스 계층은 논-리얼 타임(non-real time) 운영체제 상(operating system)에서 동작하며, 상기 적어도 둘 이상의 라디오 컴퓨터의 각각은 리얼 타임(real time) 운영체제인 라디오 운영체제(radio operating system)를 포함하며, 상기 통합 라디오 어플리케이션이 상기 적어도 둘 이상의 라디오 컴퓨터에서 동작하는,
    재구성 가능한 라디오 장치.
  13. 청구항 12에 있어서,
    상기 적어도 둘 이상의 라디오 컴퓨터 각각은
    상기 통합 라디오 어플리케이션에 동작 환경을 제공하는 라디오 컨트롤 프레임워크(radio control framework, RCF);
    상기 라디오 운영체제(radio operation system); 및
    적어도 하나의 라디오 플랫폼을 포함하는,
    재구성 가능한 라디오 장치.
  14. 청구항 11에 있어서,
    상기 관리자는 상기 기능 블록들 각각을 실행하기 위한 요구 사항, 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과, 및 상기 기능 블록들 간의 데이터 트래픽 및 컨트롤 트래픽에 대해 요구되는 쓰루풋(throughput) 중 적어도 하나를 참조하여 상기 기능 블록들을 상기 그룹들로 분할하는,
    재구성 가능한 라디오 장치.
  15. 청구항 14에 있어서,
    상기 기능 블록들 각각을 실행하기 위한 요구 사항은 점근적 표기법(asymptotic notation)으로 표기되는 상기 기능 블록들 각각의 연산 요구 사항 및/또는 메모리 요구 사항로 표현되는,
    재구성 가능한 라디오 장치.
  16. 청구항 14에 있어서,
    상기 적어도 둘 이상의 라디오 컴퓨터 각각의 기능 블록 실행 벤치마크 결과는 상기 적어도 둘 이상의 라디오 컴퓨터 각각의 벤더(vendor)로부터 수신되며, 상기 기능 블록들 중 적어도 일부에 대한 벤치마크 결과를 제공하는,
    재구성 가능한 라디오 장치.
  17. 청구항 11에 있어서,
    상기 관리자는 상기 라디오 어플리케이션 패키지의 식별자(ID), 대상 라디오 컴퓨터의 ID, 상기 대상 라디오 컴퓨터의 파이프라인 구성 정보, 및 상기 대상 라디오 컴퓨터에 설치되는 기능 블록들의 ID를 포함한 정보를 상기 라우팅 엔티티를 거쳐서 상기 대상 라디오 컴퓨터에 전달하는,
    재구성 가능한 라디오 장치.
  18. 청구항 11에 있어서,
    상기 라디오 컨트롤러 코드는 논-리얼 타임 영역에서 동작하며 컨텍스트 정보(context information)를 처리하는 구성요소로서, 실행 가능한 코드(executablecode) 형태로 상기 라디오 어플리케이션 패키지에 포함되며, 상기 라디오 컨트롤러 코드는 상기 기능 블록들 중 상기 라디오 컨트롤러가 참조하는 컨텍스트 정보를 제공하는 기능 블록이 설치된 라디오 컴퓨터 또는 상기 통합 라디오 어플리케이션의 기능 블록들이 가장 많이 설치된 라디오 컴퓨터에 설치되는,
    재구성 가능한 라디오 장치.
PCT/KR2020/012453 2019-09-16 2020-09-16 복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법 WO2021054703A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2019-0113763 2019-09-16
KR20190113763 2019-09-16

Publications (1)

Publication Number Publication Date
WO2021054703A1 true WO2021054703A1 (ko) 2021-03-25

Family

ID=74883626

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/012453 WO2021054703A1 (ko) 2019-09-16 2020-09-16 복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법

Country Status (2)

Country Link
KR (1) KR20210032293A (ko)
WO (1) WO2021054703A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100883381B1 (ko) * 2007-12-17 2009-02-11 한국전자통신연구원 에스디알 단말기의 응용 컴포넌트 운영 방법 및 에스디알단말기
WO2012047050A2 (ko) * 2010-10-06 2012-04-12 한양대학교 산학협력단 스마트안테나 소프트웨어 정의 라디오 단말 장치 및 소프트웨어 정의 라디오 단말 어플리케이션의 배포 및 설치 방법
WO2013154380A1 (ko) * 2012-04-12 2013-10-17 한양대학교 산학협력단 소프트웨어 정의 라디오 어플리케이션의 동작 방법
KR20150092237A (ko) * 2012-11-30 2015-08-12 코그노소스 인코포레이티드 분산된 라디오 통신 네트워크용 방법들 및 시스템들
WO2015167264A1 (ko) * 2014-05-02 2015-11-05 한양대학교 산학협력단 소프트웨어 정의 라디오 어플리케이션의 배포, 설치 및 실행 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100883381B1 (ko) * 2007-12-17 2009-02-11 한국전자통신연구원 에스디알 단말기의 응용 컴포넌트 운영 방법 및 에스디알단말기
WO2012047050A2 (ko) * 2010-10-06 2012-04-12 한양대학교 산학협력단 스마트안테나 소프트웨어 정의 라디오 단말 장치 및 소프트웨어 정의 라디오 단말 어플리케이션의 배포 및 설치 방법
WO2013154380A1 (ko) * 2012-04-12 2013-10-17 한양대학교 산학협력단 소프트웨어 정의 라디오 어플리케이션의 동작 방법
KR20150092237A (ko) * 2012-11-30 2015-08-12 코그노소스 인코포레이티드 분산된 라디오 통신 네트워크용 방법들 및 시스템들
WO2015167264A1 (ko) * 2014-05-02 2015-11-05 한양대학교 산학협력단 소프트웨어 정의 라디오 어플리케이션의 배포, 설치 및 실행 방법

Also Published As

Publication number Publication date
KR20210032293A (ko) 2021-03-24

Similar Documents

Publication Publication Date Title
WO2013154380A1 (ko) 소프트웨어 정의 라디오 어플리케이션의 동작 방법
WO2015167264A1 (ko) 소프트웨어 정의 라디오 어플리케이션의 배포, 설치 및 실행 방법
WO2019199028A1 (en) Method and device using network slicing in mobile communication system
WO2021157934A1 (ko) 무선 통신 시스템에서 네트워크 슬라이스를 생성하기 위한 장치 및 방법
WO2013154398A1 (ko) 소프트웨어 정의 라디오 어플리케이션의 배포, 설치 및 실행 방법
WO2016133338A1 (en) Electronic device and method for installing an application
WO2022025393A1 (en) Bwp allocation method, apparatus, electronic device and computer readable storage medium
WO2013115565A2 (ko) 가상 머신 관리 방법 및 이를 위한 장치
WO2020096239A1 (ko) 작업 의존성에 기초하여 컴퓨팅 작업을 서버에 스케줄링하는 방법 및 장치
WO2021054704A1 (ko) 복수의 라디오 컴퓨터들을 구비한 재구성 가능한 라디오 장치에서 기능 블록들 간의 통신 방법
WO2021187829A1 (ko) 네트워크 슬라이스와 관련된 통신
WO2021235880A1 (ko) 무선 통신 시스템에서 단말로 지역 데이터 네트워크 정보를 제공하기 위한 방법 및 장치
US10911941B2 (en) Reconfigurable radio equipment having multiple radio computers, and operation method for the same
WO2021054705A1 (ko) 복수의 라디오 컴퓨터들을 구비한 재구성 가능한 라디오 장치에서 라디오 어플리케이션을 구성하는 기능 블록들의 동적 재구성 방법
WO2022092456A1 (en) Communication method and equipment
WO2017138784A1 (ko) 라디오 어플리케이션을 실행하는 방법 및 단말 장치
WO2022114925A1 (en) Method and apparatus for cooperative scheduling in a mobile communication system
WO2016028086A1 (ko) 라디오 어플리케이션을 실행하는 방법 및 단말 장치
WO2019143181A1 (en) Method and an electronic device for dynamically controlling tcp congestion window
WO2022245114A1 (en) Carrier management method, resource allocation method and related devices
WO2021054703A1 (ko) 복수의 라디오 컴퓨터를 가진 재구성 가능한 라디오 장치에서 통합 라디오 어플리케이션의 분산 설치 방법
WO2016171477A1 (ko) 통합 라디오 어플리케이션의 관리 방법 및 이를 이용하는 재구성 가능한 모바일 장치
WO2014171780A1 (ko) 라디오 어플리케이션을 실행하는 단말 장치
WO2023063776A1 (ko) 대역폭 부분을 이용하여 통신을 수행하는 전자 장치 및 네트워크와 그들의 동작 방법
WO2022103181A1 (ko) 소프트웨어 패키지에 gpu를 할당하는 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20864556

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20864556

Country of ref document: EP

Kind code of ref document: A1