JP6069309B2 - General-purpose multi-radio access technology - Google Patents

Description

Related Applications This application is a US patent application 61 / 493,795 of Jerker ORJMARK, Michael BRESCHEL, Kent Inge INGESSON, Robert KLANG and Magnus MALMBRG filed June 6, 2011, which is incorporated herein by reference. "METHODS AND SYSTEMS FOR A FLEXIBLE DISTRIBUTED SEQUENCER", Jerker ORJMARK filed June 6, 2011, and Kent Inge INGSONSON and Robert KLANG US Patent Application No. 61 / 493,801N Jerker ORJMARK, Ken filed on June 6, t Inge INGESSON and Robert KLANG US Patent Application No. 61 / 493,794 “METHODS AND SYSTEMS FOR A GENETIC MULTI-RADIO ACCESS TECHNOLOGY LAYER ONE SOFTWARE AUTHOR ARE

TECHNICAL FIELD The present invention relates generally to communication devices, and more particularly to devices related to multiple radio access technologies.

  Initially, radiotelephone technology has been designed and used for voice communications. As the consumer electronics industry continues to grow and processor capabilities improve, more devices are available that can wirelessly transmit data between multiple devices. Further, more applications that operate based on such transmission data can be used. Of particular note are the Internet and local area networks (LANs). These two innovations have allowed many users and many devices to communicate and exchange data between different devices and between different types of equipment. With the advent of these devices and functions, users (both business users and home users) have noticed an increasing need to transmit data from the destination in addition to voice.

  Infrastructure and networks that support this voice and data transmission have developed as well. Limited data applications such as text message communication have been introduced in so-called “2G” systems such as the Pan-European Digital Mobile Communication System (GSM). Packet data via a wireless communication system has been realized in GSM plus General Packet Radio Service (GPRS). The 3G system introduced by the Universal Terrestrial Radio Access (UTRA) standard has allowed many users to more easily (and with lower latency) access to applications such as web surfing. Thus, many radio access technologies (RATs) such as, for example, wideband code division multiple access (WCDMA), OFDMA, TDMA, and TD-SCDMA are currently available, eg, GSM / GPRS / EDGE, UMTS, UMTS-LTE, WLAN, It is seen that it is used in wireless systems such as WiFi.

  As new network designs are provided by network manufacturers, future systems that provide higher data throughput to end-user devices are being considered and developed. For example, the so-called 3GPP LTE (Long Term Evolution) standardization project is intended to provide a technical infrastructure for future wireless communications. As a result of this advance in network design, different network operators have deployed their networks in different frequency bands using different RATs in different geographic regions. Therefore, a user equipment (UE) that supports at least one of a plurality of frequency bands and a plurality of different RATs can search for a cell and a service in at least one of the appropriate frequency band and the RAT, among others. There is a need.

  New standards for mobile phone technology and other communication technologies have been rapidly developed, and new features have been added to existing standards more rapidly, increasing the design cost of devices that use existing architectures. For example, a device that allows access to a particular RAT typically has a software (SW) architecture that is adapted to that RAT and its current characteristics. If a new RAT or feature is added to the architecture of a multi-RAT UE device, in addition to the new RAT / feature need to be realized in that architecture, it needs to be adapted to the conventional implementation, This process typically has a significant impact on software implementation and significantly increases the cost of the device.

  In the method of introducing a new RAT or introducing a new function into an existing RAT, the UE SW architecture becomes complicated, and it becomes difficult to make the necessary changes to adapt to such changes. In addition, the integration is more complex and costly because its development is often done in different geographic locations that may be located on different continents.

  In addition to software architecture changes, hardware changes may be further necessary or desirable due to RAT adaptation at the UE. For example, in multi-RAT UEs, it is often desirable to share (as much as possible) the hardware (HW) in the system. One example of hardware that may be shared within a multi-RAT device is a HW accelerator. However, each user of the HW accelerator (ie, RAT) needs to maintain its own environment to avoid unnecessary ties with other RAT algorithms or modules, ie, to avoid reliance on them. is there. One way to allow each user to maintain their environment is to use multiple register pages in the HW accelerator. However, the number of pages available in that register is fixed in the silicon design associated with multi-RAT UEs and cannot be changed later. Therefore, this separation method is somewhat less flexible when adding RATs or features later.

  Furthermore, with respect to the algorithms used in multi-RAT devices, these algorithms are implemented in either software (SW) or hardware (HW), and are usually more unnecessarily tied to each user or RAT. This association or dependency may cause unwanted redesign of neighboring blocks when one block is changed at the UE (or a subcomponent of the UE). Also, as the number of RATs increases, unknown dependencies and side effects can arise from other parts of the system, which would be undesirable. Furthermore, in a multi-RAT system, as the data rate increases and the transmission time interval (TTI) decreases, the interrupt load increases in a system designed with a central controller.

  Furthermore, for example, when adding a new function to the UE, such as an additional RAT function, a new combination of usage patterns must be considered and then hard-coded, so that paging channel (PCH) reception and Dependencies between different activities such as measurements make such an implementation cumbersome. Layer 1 RAT software typically uses radio for different purposes such as channel reception and measurement. In conventional multi-RAT architectures, there is no common plan between RATs, so it is difficult to handle specific usage patterns where the active RAT cannot distribute the required radio time. In order to avoid contention for radio usage, each usage, such as paging channel reception and serving cell measurement, is usually combined and / or synchronized. However, conflicts are not necessarily resolved and proper processing between multiple RATs / functions may not be possible.

  In addition, when adding more RATs to the multi-RAT architecture (eg compared to having only GSM and W-CDMA architectures in the device), the active RAT gives radio time out of many passive RATs. This is further complicated by the need to determine the RAT to be performed. When adding a new RAT, the existing RAT needs to be updated to recognize the details of the radio request associated with the new RAT. If the active RAT and the passive RAT are not well coordinated, radio use contention may occur. Radio access contention detection includes, for example, specific hardware that solves the potentially huge signal transmission problem between RAT modules related to radio access time processing that becomes very complex as the number of RATs increases Design is needed. Because many interrupt signals and other signals are required, current solutions are inefficient and error prone. Existing solutions for adding additional RAT functionality to the UE are also less power efficient, for example, due to the large amount of signal transmission and each RAT module needs to recognize all other RATs in the device .

  Accordingly, it would be desirable to provide a method and system that mitigates or eliminates the aforementioned shortcomings associated with multi-RAT devices.

  According to an exemplary embodiment, the configuration of an apparatus for processing data includes a processor configured to perform a plurality of procedures associated with different radio access technologies (RATs), and radio resources from the plurality of procedures. Generated by at least one of the plurality of procedures and a radio planning function configured to receive the request and further configured to selectively permit or deny radio access by the procedure in response to the request And a memory device configured to operate as a distributed database that stores stored data and provides data to at least one other of the plurality of procedures.

  According to another embodiment, a multi-RAT wireless communication device comprises the configuration described in the previous paragraph.

  According to another embodiment, a method for processing data in a multi-radio access technology (RAT) device includes generating a procedure to perform a plurality of functions associated with different radio access technologies (RAT), Storing the data generated by at least some of the procedures in the distributed database, retrieving the data from the distributed database for multiple procedures that use the data, and the radio planning function Receiving and processing radio resource requests from at least some of the plurality of procedures.

  According to another exemplary embodiment, a persistent computer readable medium comprises a plurality of procedures that, when executed by a computer or processor, perform a plurality of functions associated with different radio access technologies (RATs). Generating, storing data generated by at least some of the plurality of procedures in the distributed database, retrieving data from the distributed database for the plurality of procedures on the data use side, and And a program instruction for performing, by the radio planning function, receiving and processing radio resource requests from at least some of the plurality of procedures.

  According to another embodiment, an apparatus configuration includes a multi-radio access technology (RAT) platform configured to enable communication with a plurality of different RATs using a plurality of procedures associated with transmit / receive processing functions. Including. These procedures are realized by at least one of hardware and software, and realize a transmission / reception processing function via a plurality of functional units (FUs) that perform operations. These FUs are (a) data for operation Or at least one of: (b) a memory location for storing data that is the result of an operation; and (c) a type of message that is output after the operation. Configured by a plurality of functional unit descriptors (FUD) that give instructions to the FU.

  According to another embodiment, a multi-RAT wireless communication device includes the configuration of the preceding paragraph.

  According to another embodiment, a method for distributing and implementing a plurality of radio communication functions generates a plurality of procedures for performing a plurality of transmission / reception processing functions that enable communication with a plurality of different radio access technologies (RATs). A step of realizing the plurality of transmission / reception processing functions via a functional unit (FU) that is realized by at least one of hardware and software and that executes a plurality of operations, and (a) data for operation or At least one of: a storage location for fetching parameters associated with operations performed by the FU; (b) a storage location for storing data resulting from the operation; and (c) a type of message output after execution of the operation. Configuring the plurality of FUs with a plurality of functional unit descriptors (FUD) that provide instructions to the FU with respect to one.

  According to another exemplary embodiment, a persistent computer readable medium is a plurality of transmit / receive processing functions that, when executed by a computer or processor, enable communication with a plurality of different radio access technologies (RATs). The plurality of transmission / reception processing functions are realized via a plurality of functional units (FU) that execute a plurality of transmission / reception processing operations, and are realized by at least one of hardware and software. A process, (a) a memory location for fetching parameters related to the operation to be performed by the data or FU to operate, (b) a memory location for storing data resulting from the operation, and (c) execution of the operation A plurality of functional unit descriptors (FU) that provide instructions to the FU regarding at least one of the types of messages to be output later ) The include program instructions for performing the step of configuration the FU.

  According to another exemplary embodiment, a method for avoiding contention between resource requests of multiple radio access technology (RAT) modules includes, in a radio planning function, each including a priority value for a radio time reservation request. A step of receiving a radio time reservation request, a step of determining permission or rejection of each radio time reservation request for comparison of priority values based at least in part by a radio planning function, and a step of determining And transmitting either a permission or a denial corresponding to the corresponding radio time reservation requesting side.

  According to another exemplary embodiment, a platform that allocates radio resources among multiple radio access technology (RAT) modules is configured to transmit and receive radio signals over an air interface using multiple RATs. And wireless hardware connected to the wireless hardware, each receiving a wireless time reservation request including a priority value of the wireless time reservation request, and each wireless time reservation based at least in part on the priority value A radio planner configured to determine whether the request is allowed or denied.

  According to another exemplary embodiment, a persistent computer readable medium, when executed by a computer or processor, in a radio planning function, each includes a radio time reservation request including a priority value for a radio time reservation request. A step of receiving a request, a step of determining permission or denial of each radio time reservation request based on a comparison of priority values, at least in part, by a radio planning function, and a response based on the step of determining And a program instruction for executing a step of transmitting either a permission or a denial corresponding to the wireless time reservation requesting side.

  According to an exemplary embodiment, there is a software architecture for layer 1 for accessing a wireless communication system. Its software architecture is configured to terminate control planes from higher layers, procedures configured to use the radio planner, and radios configured to manage and allow access to the common radio It includes a planning unit, a distributed database configured to separate a generation side and a usage side of the same data, and a functional unit configured to encapsulate functionality. The functional unit can further include a configuration interface and algorithm. The software architecture can further include a session configured to build multiple chains of multiple functional units to configure uplink and downlink processing. The software architecture can further include a resource manager configured to collect and allocate resources for all sessions.

  According to another exemplary embodiment, there is a method of using a software architecture for layer 1 for accessing a wireless communication system. The method terminates the control plane from the upper layer according to the procedure, uses the radio planning unit, manages and permits access to the common radio by the radio planning unit, and distributes the same data using the distributed database. A step of separating a generation side and a use side, and a step of encapsulating functionality by a functional unit.

  According to another embodiment, a device is general to any of a plurality of radio access technologies (RATs) that can be used when an encapsulated hardware functional unit receives instructions and the device communicates. A processor operable to encapsulate at least one hardware functional unit to generate a response having the following: a processor configured to execute program instructions stored on a computer-readable medium; And a distributed database configured to allow data producers and data consumers to exchange data indirectly.

  According to an exemplary embodiment, there is a method for processing data in a multi-radio access technology (RAT) user equipment (UE). The method comprises the steps of building a logical model, providing physical assignments to a plurality of logical objects, committing resource usage, and processing data by a plurality of functional units (FUs). Including.

  According to another exemplary embodiment, there is a method for processing data in a multi-radio access technology (RAT) user equipment (UE). The method includes reading a sample from a wireless interface, configuring a plurality of functional unit descriptors (FUD), associating the functional unit (FU) with each of the plurality of FUDs, and the plurality of FUDs. Sending at least one instruction from each to the FU associated with it; sequentially processing at least one instruction received by the FU and processing a signal by each FU based on the received at least one instruction; And outputting a data block. Furthermore, each FU may be associated with multiple FUDs.

  According to another exemplary embodiment, there is a functional unit (FU) that processes the algorithm. The FU includes an input port unit that receives the first message, a functional unit unit that processes the first message, and an output port that transmits the second message based on the processing of the first message.

  According to another exemplary embodiment, there is a functional unit descriptor (FUD) that constitutes a functional unit. The FUD includes first information related to one or more storage locations used by the functional unit (FU) and second information related to one or more messages that the FU sends after processing the message. .

  According to another exemplary embodiment, a multi-radio access technology (RAT) user equipment (UE) corresponds to a plurality of RAT modules each configured to allow the multi-RAT UE to communicate with different RATs. A processor configured to execute a function without depending on the RAT module by calling the functional unit, and execution of one instance of a plurality of functions by the corresponding functional unit is specified by the functional unit descriptor Is done.

  According to an exemplary embodiment, there is a method for avoiding contention between resource requests of multiple radio access technology (RAT) modules. The method includes the steps of assigning a priority to a radio time reservation request, requesting a radio time reservation request including the priority, and receiving either a grant or a denial of the radio time reservation request. In response to the received radio time reservation request, the radio time is specified using a unified time reference.

  According to an exemplary embodiment, there is a method for avoiding contention between resource requests of multiple radio access technology (RAT) modules. In the radio planning function, the method includes a step of receiving a radio time reservation request including a priority of the radio time reservation request, a step of determining permission or rejection of the radio time reservation request based on the priority, and a radio time reservation. Allocating a unified time reference for the radio time reservation request if the request is granted, and transmitting either permit or deny based on determining whether to allow or deny the radio time reservation request. .

  According to another exemplary embodiment, there is an apparatus that avoids contention between resource requests of multiple radio access technology (RAT) modules. The apparatus is configured to request a radio time reservation, at least two RAT modules configured to assign a priority to the radio time reservation request, and grant or deny the radio time reservation request based on the priority. Configured to determine and configured to assign a uniform time base for radio time reservation requests when radio time reservation requests are allowed, and permit or deny radio time reservation requests based on permit or deny decisions And a processor having a radio planning function configured to transmit any of the above.

  According to another exemplary embodiment, a device includes a plurality of radio access technology (RAT) modules each configured to allow radio communication between the device and a corresponding RAT network; A radio planning module configured to receive radio access requests from one or more of the RAT modules and selectively grant each radio access request. Upon receiving a radio access request grant signal from the radio planning module, the corresponding RAT module in the device can initiate radio access by sending one or more signals to the corresponding RAT network.

  The accompanying drawings illustrate exemplary embodiments. The drawings are as follows.

FIG. 2 illustrates a layer 1 architecture according to an exemplary embodiment. FIG. 2 is a diagram illustrating a typical usage pattern used to describe the operation of the layer 1 architecture of FIG. 1. It is a figure which shows the various procedures produced | generated as a part of the typical usage pattern of FIG. 1 is a diagram illustrating an apparatus according to an exemplary embodiment. 6 is a flowchart illustrating a method according to an exemplary embodiment. 6 is a flowchart illustrating a method according to another exemplary embodiment. It is a figure which shows the functional unit (FU) which concerns on typical embodiment, and the functional unit descriptor (FUD) which comprises the FU. It is a figure which shows the chain of several FU concerning one typical embodiment. FIG. 3 is a diagram illustrating a chain of a plurality of FUs having two FUDs according to an exemplary embodiment. It is a figure showing FUD concerning one typical embodiment. It is a figure which shows the information flow concerning one typical embodiment. 6 is a flowchart illustrating a method according to an exemplary embodiment. It is a figure which shows the radio | wireless plan part used as the interface between several RAT module and radio | wireless hardware which concern on one Embodiment. , 6 is a flowchart illustrating a method according to an exemplary embodiment.

  The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numerals in different drawings denote the same or similar elements. Further, the drawings are not necessarily to scale. Also, the following detailed description does not limit the invention.

  When referring to “one embodiment” or “an embodiment” herein, a particular feature, structure, or characteristic described in connection with the one embodiment is included in at least one embodiment of the disclosed subject matter. Means that Thus, the phrases “in one embodiment” or “in an embodiment” as used throughout this specification do not necessarily indicate the same embodiment. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

  As mentioned above, when a new radio access technology (RAT) or feature is added to a multi-RAT user equipment (UE), it is necessary not only to realize the new RAT / feature but also to adapt the conventional implementation further. There is usually a significant impact on software and hardware implementation. Typically, for example, dual or multi-RAT layer 1 (L1) software (SW) is implemented as a set of related RATs that use few common functions and have only a separate interface and a simple interface between RATs. Is done. The problems associated with such a technique are as described above.

  According to an exemplary embodiment, non-RAT-centric Layer 1 software that strongly separates the features that are not normally linked by the radio access technology (RAT) -centric Layer 1 structure and the associated radio communication standard, eg, 3GPP standard (SW) and / or hardware architecture is provided. This is accomplished, for example, by identifying architectural elements that are instantiated and specialized to implement some access technology or feature, for example, interfaces, services, procedures, sessions, and functional units (FUs). The For example, a common entity that is a radio planning unit, a resource manager, a radio FU, and a timer FU described below provides non-RAT-centric services for all features. Furthermore, in the embodiments described herein, means are provided that allow them to exchange information without strongly tying features, for example by using a distributed database.

  According to an exemplary embodiment, the generalized multi-RAT architecture allows distribution of architectural elements such as interfaces and FU message protocols across one or more central processing units (CPUs) / cores. In addition, the architecture enables support for moving functions, such as multiple FUs, and changing HWs between CPUs, digital signal processors (DSPs) and hardware (HW) accelerators. Multiple sets of rules are defined for the method of implementing the application code (in services, procedures, sessions and FUs), and a set of user interfaces is defined for the method of using a common entity. According to an exemplary embodiment, when using a user interface according to these rules, it is expected that features / RAT will be rarely or not tied unnecessarily, and the new features / RAT will affect traditional implementations. Added without. Similarly, features are removed to create low-cost variants from existing code bases without affecting the remaining features.

Generalized Software Architecture A generalized multi-RAT structure (including software architecture for performing the tasks and functions described below) in which the exemplary embodiments described herein are implemented in accordance with exemplary embodiments is illustrated in FIG. Will be described below. Part of this description uses object-oriented programming terminology to describe various features, but this does not necessarily indicate that those features are implemented using object-oriented programming techniques. . FIG. 1 may be viewed, for example, as a top-level class diagram (eg, for ePHY). In that case, the interface provides a function-oriented application program interface (API) to the user of the service (eg, one of the RATs) that hides the actual deployment and realization of the service. For example, layer 1 100 includes a number of interfaces that act as proxies for the server, for example, layer 1 external interface 102 and layer 1 internal lower interface 104 act as proxies for the server. According to this exemplary embodiment, the layer 1 architecture includes an upper layer 106 106, a control unit 108 (e.g. implemented in an ARM processor) and a data processing unit 110 (e.g. as a HW accelerator or CPU / DSP). And the lower part of layer 1 including The lower part of layer 1 is more dependent on the underlying hardware (usually the baseband HW in some examples). Each of these different architectural components and how their sub-elements work together to facilitate general-purpose multi-RAT operation are discussed in further detail below.

  Layer 1 upper portion 106 includes, for example, a service class that captures each service 112 and its parameter representation when requested by a user that is one of a plurality of RATs supported by layer 1 architecture 100. . Although only a single service 112 is shown in FIG. 1, the upper component 106 of layer 1 is an instance of a number of services in the service class based on user requests as indicated by reference numerals 1. 112 can be at any time. Service 112 provides a first step / mechanism for decoupling (separating) features implemented in a general multi-RAT architecture from each other.

  The service object 112 receives requests from the user (RAT) via the layer 1 interface 102 and processes the requests to determine the requested functionality (method for realizing the requested function). To distinguish). Based on the determination of this function, the service object 112 instantiates one or more procedures or procedure objects 114 that operate to implement the requested function. In this case, the procedure or procedure object 114 is considered to be a logical state machine that implements the desired function, eg, channel measurement, in a manner common to a particular RAT or to multiple RATs. The procedure 114 further operates to terminate the control plane from the upper layer to achieve external behavior (in the control plane). A procedure class is instantiated and specialized for each function provided by the layer 1 architecture 100. Each procedure 114 or group of associated procedures 114 associates with itself independently of the rest of the system, i.e., without requiring recognition of other procedures 114, handshaking with them or their involvement. Plan and set the execution of designated functions. The independent nature of procedure 114 according to these embodiments eliminates the need to rewrite or change procedure 114 when either a new feature or a new RAT location is added to the architecture.

  In order to allow the independence of procedures 114, multiple common elements, ie, elements shared by those procedures regardless of which RAT request instantiated the various procedures 114, are in layer 1 architecture 100. Provided. For example, the radio planner 116 may obtain a radio time allocation, i.e., share a physical radio transceiver between different RATs and between different procedures associated with the same RAT, according to procedure 114. used.

  According to an exemplary embodiment, the radio planning unit 116 allows multiple independent procedures 114 to exist simultaneously in a single radio environment. The radio planning unit 116 manages the common radio through the interaction with the lower layers 108 and 110 of the layer 1 and permits access to the shared radio. Before the radio is used by procedure 114, the procedure requests an assignment (eg, radio resources and dispatch time) from radio planner 116, as shown, for example, by signal line 122. The radio reservation is executed by the radio planning unit 116 based on the relative priority of radio resource requests. According to some embodiments, procedure 114 needs to receive a radio grant via dispatch signal line 124 to access the radio. Further, if a request for wireless use is rejected, for example, via signal line 126, the client (ie, procedure 114) is responsible for performing subsequent operations. Radio time is reserved in a common time format that is not RAT specific. In the header “Radio Planning Unit”, the radio planning unit 116 will be described in more detail below.

  In addition to the radio planner, the procedure 114 can further use the service 118 at the layer 1 lower interface 108 to make the procedure 114 hardware independent. However, if a client / server relationship still exists during the procedure 114 that is not strongly tied, that is, there may be a one-way relationship or connection between the two procedures similar to the client / server. The exemplary embodiment further provides a distributed database 120 so that the server portion can generate data without the data consumer being aware of it. The distributed database 120 provides a common storage area in which data is stored and retrieved by various procedures 114, thereby separating the generation side and the usage side of the same data (this is the realization of a thread-safe observer pattern). is there). Thus, the data generation side does not need to recognize the number or identifier of the data use side. For example, if a particular procedure 114 is instantiated to read and identify a cell in the neighbor list, that procedure 114 stores the resulting data in the database 120 and other procedures 114 (eg, In the measurement procedure), the adjacent list reading procedure 114 and the measurement procedure 114 can acquire the data from the database without directly interacting with each other.

  Referring now to the bottom of layer 1 in FIG. 1, an interface 104 is provided, for example, to allow client deployment on different processors. The interface 104 also transfers the request from the upper layer 106 of the architecture 100 to the control unit 108 and the data unit 110 of the lower layer 1 of the architecture 100. Similar to the method associated with layer 1 top 106, service object 118 is not a mechanism for performing a function, for example, a service at the bottom of the layer that is an instantiation of a service indicating the function that is required to be performed. Instantiated in response to receiving a solicitation request from interface 104. According to an exemplary embodiment, the session 128 implements the functionality provided by the services below layer 1 in response to a request from at least one of the procedure 114 and the radio planning unit 116. Sessions 128 are, for example, the first entity in architecture 100 where hardware recognition begins, but these sessions 128 hide both the implementation and deployment of the actual algorithm, eg, logical functional units (below The logical configuration interface for the FUs (FUs to be described) 130, 132 and 134 is further used. The session 128 constructs the FU chain to constitute a complete uplink and downlink process and to service requests associated with the instantiated service object 118. Like many other objects in architecture 100, sessions 128 that do not directly depend on each other do not recognize each other at all.

  According to an exemplary embodiment, for example, the FU represented by logical FU 134 and corresponding physical FU 140 perform operations as part of the wireless function being executed by procedure 114 (which may be more complex). For example, a well-defined functional encapsulation that is, for example, a Fast Fourier Transform (FFT). The FU is a distributed object that provides a function-oriented interface to the user, for example, a configuration setting interface part that is a logical FU 134 and an algorithm part that is a physical FU 140 that performs functionality, for example. The algorithm portion 140 is implemented in HW or SW, and its deployment is opaque to the user, ie, the RAT or procedure 114 that ultimately called the algorithm. Configuration settings interface 134 may be instantiated multiple times independently of each other by different users sharing the same algorithm implementation. Instances are connected in a self-triggered chain that allows autonomous execution without central CPU intervention during configuration time. The actual deployment and implementation of the algorithm portion 140 is similarly resolved at configuration time without the triggering FU and the triggered FU being aware of the deployment and implementation of the other FU. In order to be able to combine FUs 134, 140 implemented as HW accelerators or algorithms running on different microcontrollers or DSPs, special protocols associated with FU identifiers (FUDs detailed below) may be used. . The FUD is usually adapted depending on whether the FU is implemented in HW or SW, but may be defined in a way that can be used for both HW and SW. The L-FU 134 is used to configure the FUD in its configuration role and can also send messages to the P-FU 140. The session 128 starts the signal processing chain of the P-FU 140 using the message. The session 128 sends a message to the first P-FU 140 in the chain, and the P-FU 140 triggers each other without the session 128 or L-FU 134 involved. Further information about FU and FUD is provided in the header “Functional Unit” below.

  According to representative embodiments, various dedicated FUs are provided in the architecture 100. For example, the wireless FU 138 is dedicated to the FU class. The wireless FU 138 encapsulates the common wireless HW. Similar to the general FU 140, all users (sessions 128) create an instance of the corresponding configuration setting interface 132 independently of each other. The timer FU 136 is also dedicated to the FU class. The timer FU 136 encapsulates the common timer HW and provides a timer function to both the common part such as the radio planning unit 116 and the RAT-specific part such as the procedure 114, for example. Timer requests are reserved in a general time format that is not RAT specific. Further details regarding the FU are provided in the header “Functional Unit (FU)” below.

  According to an exemplary embodiment, the architecture 100 allows completely separated functions (session 128) to share the same hardware and software resources. In a manner similar to that of the radio planning unit 116, the common resource manager 142 may, for example, execute memory download, software memory allocation, memory space initialization, hardware power on, hardware power off, etc. Resources such as HW, DSP bandwidth, etc. are collected and assigned to all functions (session 128), so that multiple users (session 128) can use the above resources without handshaking between the sessions 128 themselves Can be shared. Thus, recognition between RATs is not performed. According to an embodiment, there is no direct communication between RAT modules or services / procedures / sessions related to different RATs. Thus, RATs function autonomously with each other and do not require handshaking.

Example of Architecture Operation According to a representative embodiment, the layer 1 software architecture 100 described above is used in a UE, eg, multiple such as LTE (Long Term Evolution) networks and Wideband Code Division Multiple Access (WCDMA) networks. RATs can coordinately access various UE resources. In particular, to better understand how the architecture 100 operates with respect to the function of separating RAT functions, starting with FIG.

  In the figure, it is assumed that the LTE / WCDMA multi-RAT UE 200 operating using the architecture 100 described above is moving in the direction of arrow 201. The UE 200 is currently served by the LTE cell 202 (eNodeB 203), but the signal strength from the serving cell becomes weaker as the UE 200 moves towards the cell boundary. Therefore, it is desirable for the UE 200 to start preparing for a possible handover to the WCDMA cell 204 (NodeB 205). Accordingly, the layer 1 interface 102 receives requests from the LET and WCDMA clients for measurements of those channels including parameters and desired measurements associated with the relevant LTE and WCDMA channels. As a result of these requests, the measurement service object 112 is instantiated that reflects the client's desire to perform the measurement. Next, the measurement service object 112 uses the received parameters to determine how to perform the measurement, as shown in FIG. 3, for example, the common measurement procedure 114a, the LTE measurement procedure 114b, and the WCDMA measurement procedure 114c. A plurality of procedures 114 are generated.

  According to this embodiment, the common measurement procedure 114a performs a measurement task common to multiple RATs (eg, associated with paging channels), which in this example is LTE and WCDMA, and the RAT-specific measurement procedures 114b and 114c are: Perform measurement tasks specific to those RATs. In this merely illustrative example, since the serving cell 202 is an LTE cell, the LTE measurement procedure 114b indicates when the measurement can be performed. Accordingly, the LTE measurement procedure 114b issues information regarding the time at which the measurement is performed (stored in the distributed database 120). Note that the LTE measurement procedure 114b is the generation side of this “measurement feasibility” data, but the LTE measurement procedure 114b according to this embodiment is the presence of the common measurement procedure 114a or the WCDMA measurement procedure 114c, or the measurement execution thereof. Don't recognize if you need possibility data. In fact, there may be any number of other additional RAT measurement procedures operating in parallel with the LTE measurement procedure 114b without having to change the LTE measurement procedure 114b.

  Other measurement procedures 114a and 114c agree to receive information regarding measurement feasibility. Therefore, when the procedure 114b in this example stores information on the location / time at which the signal strength / quality measurement can be performed in the database 120, the procedure 114a and 114c are notified. Measurement procedures 114a-114c use measurement feasibility data to request radio time to perform the necessary measurements. However, because these procedures are not aware of each other, they may request wireless usage for the same time, for example, via a wireless resource request transmitted to the wireless planning unit 116. Thus, according to this embodiment, the measurement procedures 114a-114c transmit the priority level associated with the request along with the request for radio resources. The priority level selected by each procedure 114a-114c is based, for example, on the urgency with which the procedure based on each standardized measurement requirement needs to be measured. Further information regarding priority and resource adjustments performed by the radio planner 116 is provided below.

  The radio planner 116 receives requests from the various measurement procedures 114a-114c and determines which requests to allow and which to reject based in part on the provided priority level associated with the request, for example. Thereafter, the radio planning unit 116 notifies each of the requesting procedures 114a to 114c of the determination, so that these procedures can perform appropriate operations. For example, the procedure requests a measurement service 118 from the Layer 1 lower part 108 if the request is granted, and waits for another measurement opportunity based on a notification from the distributed database 120 if the request is denied.

  Next, considering the lower layer 1 of the architecture 100 in this case, the upper layer 106 106 operates to share radio resources in a state where the various RATs are separated and independent, but the layer 1 of the architecture 1 The lower part operates to share many other types of resources such as, for example, hardware accelerators, memory, power supplies, processor (DPS) bandwidth, etc., as part of performing measurement functions, for example. It will become clear from the explanation. For example, upon receiving an LTE channel measurement request from the LTE measurement procedure 114b, the service object 118 may perform the measurement using a fixed set of parameters such as, for example, the number of correlations taken to make the measurement. Is instantiated. The service object 118 then uses one or more logical FU 134 / physical FU 140 paired chains to establish one or more sessions 128, for example, to correlate.

  In this case, the resource manager 142 operates to adjust resources used by the physical FU 140, for example, to perform correlation, avoid memory overwrites, and the like. Accordingly, in this example, the session 128 requests a resource for executing a function of loading a DSP algorithm such as FFT, a storage location for storing output data (correlation result), and the like.

  The exemplary embodiments described above provide a non-RAT centric layer 1 software architecture that allows sharing of various hardware and other resources in a particularly easily scalable manner. With reference to FIG. 4, which includes hardware that uses a software architecture 100 associated with a layer 1 structure, a representative (and very generalized) device, for example, UE 200, is described below. In the figure, device 400 communicates between processor 402 (or multiprocessor core), memory 404, one or more secondary storage devices 406, device 400 and / or various RATs and frequency bands. It includes an interface unit 408 that facilitates, as well as a layer 1 interface 102. One skilled in the art will appreciate that other (upper) layers are still present and operating on the device 400.

  In general, processor 402 controls the various components of device 400. For example, the processor 402 executes instructions that facilitate the exemplary embodiments described herein. The interface unit 408 includes one or more transceivers (eg, wireless HWs) configured to transmit and receive signals over various air interfaces associated with at least one of different RATs and frequency bands. Including. It should be noted that, for example, various other HW blocks or functions (for example, timer HW), direct connection (or encapsulation) between the block 102 and the block 408, and other units not shown in FIG. At least one of the above may be further present.

  An exemplary method associated with the operation of the layer 1 software architecture 100 is illustrated in FIG. In the figure, at step 500, the layer 1 software architecture terminates the control plane from the higher layer (eg, layer 2/3). In step 502, the layer 1 software architecture manages and grants access to the common radio by the radio planner. In step 504, the layer 1 software architecture uses a distributed database to separate the same data generator and consumer. In step 506, the layer 1 software architecture encapsulates functionality by functional units. Note that in some embodiments of the present invention, the steps of FIG. 5 may be performed in a different order or may be performed in parallel.

  According to one embodiment, based on the above description, the configuration for processing data determines a radio resource from a processor configured to perform a procedure associated with a different radio access technology (RAT) and the procedure. A radio planning function configured to receive the request and further configured to selectively permit or deny radio access by the procedure in response to the request, and generated by at least one of the plurality of procedures And a memory element configured to operate as a distributed database that stores data and provides data to at least one other of the plurality of procedures.

  According to another embodiment, a method of processing data in a multi-radio access technology (RAT) device includes the steps shown in FIG. In the figure, in step 600, a procedure is generated to perform functions associated with different radio access technologies (RAT). At least some of the plurality of procedures generate data, which is stored in the distributed database (step 602) and then retrieved from the distributed database by the procedure that uses the data (step 604). . In other words, this separates the procedure for generating data from the procedure for consuming data. The radio planning function receives and processes the request for radio resources, as shown in step 606.

Functional unit (FU)
As described above, the exemplary embodiments described herein include, among other things, modularity, distributed autonomous processing without central processing unit (CPU) intervention (leading to a reduced interrupt rate), eg, wireless Methods and systems are provided that allow hardware (HW) to be shared between any number of users without linking users that are access technology (RAT) modules. Such modularization is particularly the result of encapsulating the processing into independent functional units (FUs) briefly described above with respect to FIG. Module-based architectures are easy to analyze and design, and are more resistant to change. When the term modularization is used in this specification, a direct connection between modules, for example RAT modules, is not allowed.

  Each FU according to these embodiments represents a well-defined function such as, for example, a Fast Fourier Transform (FTT) algorithm. The FU is realized by SW, HW, or a combination thereof. A FU is modeled as a completely stand-alone entity without recognizing or relying on other FUs. Note that this description of FUs is applicable to FUs operating in the general layer 1 software architecture described above, but such FUs may be used in other architectures as well, if desired.

  With reference to FIG. 7, for example, FU 700 and associated functional unit descriptor (FUD) 702, which are L-FU 134 and P-FU 140 of FIG. 1, will be described below. Each FU 700 has two ports, one input port 704 and one output port 706. The FU 700 uses, for example, the FUD 702 as one or more parameters for the corresponding function of the FU 700 that performs the FFT. From the FUD 702, the FU 700 further obtains references associated with, for example, a location to fetch and store data (eg, in memory or a register). To point out the similarities between modularization and object-oriented programming proposed in these embodiments, if FU 700 represents a class, and FU 700 is configured with FUD 702, this is an instantiated FU. It looks like an object.

  According to an exemplary embodiment, the message that FU 700 receives at input port 704 specifies a location in memory of FUD 702. The FUD 702 specifies either or both of (1) how the function is performed and (2) what message is sent on the output port 706 upon completion of execution by the FU 700. Thus, the concept of FU 700 describes the abstract usage of ports as a combination of message passing and memory sharing architecture. The FUD 702 contains a reference to the memory where the immediate parameter value or further data is located. For example, the FUD 702 specifies the location of both the input data buffer and the output data buffer, and specifies a message to be sent when execution is complete.

  Each message received by the FU 700 specifies a different FUD 702 with a different set of parameter values and a new context. According to one embodiment, context is typically not maintained in FU 700 between calls. Further, according to an embodiment, the FU 700 is not recognized or dependent on other FUs 700 and is modeled entirely as a stand-alone entity. By using the parameters of input port 704, output port 706 and FUD 702, FU 700 can be configured to relate to multiple simultaneous processing chains as established by session 128 described above. The FU 700 is still unaware of its context and reacts only when it receives a message.

  According to an exemplary embodiment, a typical digital baseband example using the architecture described above begins with reading samples from the air interface and ends with outputting data blocks to higher layers. The signal processing is executed in a plurality of steps by different units, for example, a plurality of chain-like FUs 700. Each FU 700 is configured to send one or more messages on output port 706 when it completes its function. The destination address of the output message is designated by the FUD 702 and given to the FU 700. The port connects the FUs and drives the signal processing chain until complete, with one FU starting the next FU, as shown in FIG.

  FIG. 8 shows a first functional unit FU-A 800 that sends a message 802 via an output port 804. The message 802 is received by the input port 806 of the second functional unit FU-B 808. The FU-B 808 executes the received instruction in the message 802 and transmits another message 812 via the output port 810 based on the result. Accordingly, these ports are used by FU-A 800 to initiate FU-B 808.

  According to an exemplary embodiment, as described above, the purpose of the FUD 702 is to specify function parameters, specify a location where the FU 700 fetches input data, specify a location where the FU 700 stores output data, and upon completion of processing. This is a designation of a message (at the output port 710) transmitted by the FU 700. An example of this is shown in FIG. In the figure, there are two FU instances, namely FU-A 900 and FU-B 902. In this example, both FU-A 900 and FU-B 902 have unique FUDs, for example FU-A: FUD 904 and FU-B: FUD 906, respectively. In this example, the FU-A: FUD 904 specifies the location in the memory 908 that stores the calculated value from the operation of the FU-A 900 and the message that the FU-A 900 sends upon completion of execution. FU-B: FUD 906 specifies the location in memory 908 from which FU-B 902 reads input for calculation. By following this representative scheme, data from FU-A 900 is supplied to FU-B 902 without the presence of either FU-A 900 or FU-B 902 (eg, via memory 908). And). Furthermore, those skilled in the art will appreciate that according to at least some embodiments, two FUs can exchange messages without being “next” to each other, ie, without being serial FUs in the chain. . In other words, embodiments include a mechanism that allows all FUs to send messages to all FUs, regardless of where the FU is located and whether the FU is implemented as HW, SW, or a combination thereof.

  According to the exemplary embodiment, by using the concept shown in FIG. 9, it is not necessary to change the FU-A 900, and the FU-A 902 can be removed by making a small change to the FU-A: FUD 904. It can be easily replaced with the functional unit FU-C (not shown). Furthermore, if another context that triggers another FU-A 900 (eg, parallel to the current context) further includes FU-A 900, this can be done by adding a FUD that specifies this new context. Achieved.

  From the above, it will be appreciated by those skilled in the art that the FU class may be instantiated any number of times, and each instance has its own FUD 702 that describes a particular way to perform the functions of the FU 700. The message of the input port received by the FU 700 specifies the FUD 702 to be used. According to an exemplary embodiment, FUD 702 is a mechanism used to connect two or more FUs 700 and customize the functionality of the FU.

  According to an exemplary embodiment, FU 700 is implemented as a distributed object. The FU 700 includes a configuration setting interface portion that provides a function-oriented interface to a user, for example, the logical FU 134 of FIG. 1, and an algorithm portion that performs functions, for example, the physical FU 140 of FIG. The algorithm part is realized by HW or SW, and the development of the algorithm is opaque to the user. The configuration interface portion may be instantiated multiple times by different users sharing the same algorithm instance. The configuration settings interface hides the actual development and implementation of the algorithm part. The FUs 700 are connected in a self-triggered chain using a configuration interface, ie each instance creates its own context using its own FUD 702. An example of a structure related to such a control plane will be described later with reference to FIG.

  According to an exemplary embodiment, FU 700 communicates with messages and shared memory buffers. The message received by the FU 700 at the input port 704 is a job mail. This message need not contain data. Instead, the message contains some form of pointer to FUD 702. FUD 702 is considered an instruction stream. Logically, the instruction stream of FUD 702 is divided into two parts, a pre-instruction 1000 and a post-instruction 1002, as shown in the FUD structure example of FIG. The advance instruction 1000 is located in the input area of the FUD 702. These include setting instructions for the FU 700. The pre-instruction 1000 is executed before the FU 700 executes the function, and the post-instruction 1002 is executed after the FU 700 completes the function.

  According to an exemplary embodiment, the post-instruction is for sending a specified message to the next FU 700 in the chain by writing a register value to a specified memory address or by placing a message at a port. is there. Accordingly, each FU 700 is configured to send a message on the output port 706 that includes an “address” destined for the next FU when it completes its function. Thus, the port connects the FU 700 and drives the signal processing chain until complete, with one FU 700 starting the next FU 700. Again, the above description is not intended to indicate that there is necessarily a fixed order of FUs, and those skilled in the art will understand that FUs may be executed in any desired order according to the session. It should be.

  According to an exemplary embodiment, instructions in the input and output areas of FUD 702 are composed of actions and values or value pairs. Although the operation is different for different types of FU 700, according to one embodiment, there are four main groups: (1) a command that configures FU 700 with parameters, input data and a command to start FU 700, (2 There are commands for generating output data from the FU 700, (3) commands for sending messages to other FUs 700, and (4) commands for sending trace messages to the trace / debug block. The value or value pair associated with the operation is, for example, a value indicating the memory address of the buffer or the length of the transport block of the decoder.

  According to an exemplary embodiment, for example, an L-FU (logical LU) such as L-FU 134 is related to configuration settings, and L-FU 134 is a P-FU (physical FU) such as P-FU 140, for example. Also used as a proxy for. In the latter example, the session instructs the L-FU 134 to pass the message to the P-FU 140. Execution is started by this trigger, and one P-FU 140 triggers the next P-FU. Therefore, the configuration flows in the vertical direction from the session to the P-FUD / P-FU via the L-FU, and the data flows in the horizontal direction between the P-FUs.

  According to an exemplary embodiment, the configuration and data flow associated with these L-FUs 134 occurs as shown in FIG. Initially, there is a user application 1100 that communicates with one or more configuration settings interfaces 1102, 1104, and 1106 that represent various L-FU 134 configuration settings aspects. Each configuration setting interface 1102, 1104, and 1106 transmits configuration setting information to each FUD 1108, 1110, and 1112. Thereafter, each FUD 1108, 1110 and 1112 sends a command to the FU or provides setting information corresponding to the configuration setting information. As a result, the P-FU 140 executes instructions as indicated by the sequentially executed algorithms 1114, 1116 and 1118. FIG. 11 further illustrates various flows and steps of information related to the elements described above. For example, configuration setting information flows from top to bottom as shown by arrow 1120 as illustrated above, and resource allocation is resource manager 1122 (also described above as element 142 in FIG. 1) as shown by arrow 1123. And various configuration interface 1102, 1104, and 1106. For example, the data flow that is the execution of the FU is performed in the horizontal direction as indicated by an arrow 1124. Relative direction terms such as “vertical” and “horizontal” in the foregoing description are primarily used to align the reader's orientation with the example shown in FIG. Those skilled in the art will appreciate that, in embodiments, information flow is defined by various paths that may or may not be adequately depicted using directional terms or geometric terms. .

  According to an exemplary embodiment, to correlate the above description of FUs and FUDs with their overview in FIG. 1, the first step in executing the chain of FUs 700 is to build a logical model. Therefore, the logical model is built before the start of execution. The logical object then gets a physical allocation from the resource manager 142 or 1122 and the use of the resource is committed. As will be further appreciated by those skilled in the art, committing resources in this case may involve staggering rather than allocating all of the required resources immediately at the same time. Thereafter (usually not earlier), the session 128 or user application 1100 sends a trigger (via L-FU 134) to the P-FU 140 that initiates the data processing.

  As described above, the P-FU 140 is realized by at least one of SW and HW. Depending on the implementation, the FU 700 has different properties. The HW P-FU 140 is configured using a P-FUD. The P-FUD may or may not have an output area that is considered to be executed when main execution is performed. Since other “mail” operations are not executed while the FU chain associated with the task or job is being executed, this output area is also referred to as “job mail” in this specification. On the other hand, there are also HW FUs that are not configured via P-FUD. In such a case, the HW FU is configured using simple write mail instead of using job mail. One drawback of the latter embodiment is that job mail guarantees the autonomous operation of the FU related to the job, whereas in the write mail embodiment, there is no way to store the write mail together in the system. Therefore, autonomous operation is not guaranteed.

  According to an exemplary embodiment, the SW FU is similarly configured using P-FUD. The P-FUD in the case of the SW FU can be regarded as a configuration setting structure for the FU. The SW FU may include a memory that is, for example, a FU 700 that implements a filter. The results are stored (along with static variables) in the P-FUD or FU 700's own buffer (or other memory or register). In the latter case, the FU 700 may be used in only one session (because it is not memoryless).

  The session adjustment unit (SC) is unique to SW FU. Like other FUs 700, the SC communicates with messages. The SC differs from the normal FU 700 in that it recognizes its context and can be used to control other physical FUs at runtime. For example, the SC redirects, pauses, synchronizes, or transfers a process flow in a session. For example, assume that the function is performed using one FU 700 that uses inputs from two other FUs 700. In this case, an SC is provided that waits for messages from two other FUs 700, and if both messages arrive, the SC forwards the message to the FUs 700 that are waiting for these two inputs to perform autonomous operation. To do. Typically, an SC according to one such embodiment is similar to the FU 700 in that it includes a minimal amount of control logic and operates as a small entity that may be reused (depending on complexity). The main difference between the FU 700 and the SC is that the SC may recognize and rely on the session state. SC can be seen as a way for a session object to delegate some task to an entity that is close to the actual baseband processing.

  According to an exemplary embodiment, similar to FU 700, the SC is modeled as an L-FU in a session tree that represents a P-FU 140 that implements the SC function. Since the P-FU 140 has different properties, it is denoted herein as P-SC.

  According to an exemplary embodiment, there are at least three dedicated FUs (some of which are shown in FIG. 1) as follows: That is, (1) a timer FU 136 that manages the timing generation unit TIMGEN, (2) a radio FU 138 that manages radio, and (3) an interface FU that is an interface to parts other than the FU. Wireless FU 138 is the first FU in the receiver (RX) chain and the last FU in the transmitter (TX) chain. Further, the wireless FU 138 is considered to be a mixed FU, i.e., the wireless FU is a SW FU that controls the HW device. Regarding the interface FU, in the case of the data plane, the RX chain ends with the interface FU, and the TX chain starts with the interface FU connected to the media access control (MAC) layer. For example, any SW P-FU executing on the processor may be used as the interface FU. A separate interface FU is only needed, for example, when passing information from a digital signal processor (DSP) or HW FU to the media access control (MAC) layer or PMSS.

  According to the exemplary embodiments described herein, using the FU / FUD framework described above, (1) encapsulating functionality and (2) SW being opaque to the user / application Implementation in at least one of the HWs, (3) complete context given per call (eg, suggesting improved testability and concurrent use), and (4) comparison with conventional methods and systems Thus, at least one of the autonomous self-trigger chains with a low interrupt rate in the central microcontroller can be enabled. When testing an algorithm (HW or SW), the smaller the context the algorithm has, the smaller the state event space that needs to be considered in the test. Therefore, a well-defined context that does not have unknown dependencies and / or side effects from other parts of the system is beneficial in many ways.

  As described above in the example of FIG. 2, FU 700 and FUD 702 are used in a multi-RAT UE to perform various functions associated with a multi-RAT environment. For example, the cell search function is usually performed by a multi-RAT UE when attempting to connect to the network. Cell search examines the carrier frequency to determine if an actual cell is present on the carrier or if the measured energy is just noise. In this example, a first chain consisting of a plurality of FUs 2 having a plurality of associated FUDs 4 is executed by multi-RAT. This first chain is created and executed for the WCDMA environment, performs a cell search, correlates the measured signal with various scrambling codes (stored in memory), and finds a match. To determine if the cell can be found. A second chain is created and executed for the GSM environment and performs a cell search that decodes a base station identification code (BSIC) to determine if the carrier is associated with an actual cell. It will be appreciated by those skilled in the art that the above example is merely illustrative, and that there are many different FU chains implemented to perform many radio functions in a multi-RAT UE or platform designed according to these principles. It will be.

  Accordingly, a configuration or apparatus according to an embodiment is a multi-RAT platform configured to enable communication with a plurality of different radio access technologies (RATs) using a plurality of procedures associated with a plurality of radio functions. including. Here, these procedures are realized by at least one of hardware and software, and a plurality of wireless functions are realized via a plurality of functional units (FUs) that perform operations. The plurality of FUs are (a) A storage location for fetching data for the operation; (b) a storage location for storing data resulting from the operation; and (c) a plurality of functional unit descriptors that indicate to the FU the type of message to be output after the operation ( FUD).

  Similarly, a flowchart of FIG. 12 shows a method for realizing a plurality of wireless communication functions in a distributed manner. In the figure, at step 1200, a plurality of procedures are generated to perform a plurality of radio functions that enable communication with a plurality of different radio access technologies (RATs). In step 1202, the plurality of wireless functions are realized by at least one of hardware and software, and are realized by a plurality of functional units (FUs) that perform a plurality of wireless operations. As shown in step 1204, the plurality of FUs are (a) a memory location for fetching data for the operation, (b) a memory location for storing data resulting from the operation, and (c) execution of the operation. It is composed of a plurality of functional unit descriptors (FUD) that indicate to the FU the type of message to be output later.

Radio Planning Unit As described above, according to an exemplary embodiment, a single radio access technology (RAT) usage such as, for example, a paging channel (PCH) is measured to determine what one (or multiple). ), The common radio planner 116 (shown in FIG. 1) in the user equipment (UE) considers all (or some subset) of the radio access requests. Thus, for example, conflicts such as simultaneous conflicts are resolved. Therefore, before the use of the radio is executed, a radio time reservation according to the procedure 114 is requested from the radio planning unit 116, and if the request is permitted, the radio is used. The radio time is specified, for example, using a unified time reference in order to avoid errors in RAT time conversion. Accordingly, each RAT module or procedure transmits a radio access time request to the radio planning unit 116 and receives permission or denial from the radio planning unit. Each request / reservation is prioritized by the user, for example, PCH reception has a higher priority compared to measurement. According to an exemplary embodiment, some priority may be set by the end user (human) in addition or instead. For embodiments that include two competing reservations, access is granted to the reservation with the highest priority and other reservations are denied (or time moved if it is a dynamic request as described below). )

  It should be noted that this discussion regarding the radio planning unit is applicable to the radio planning unit 116 operating in the general layer 1 software architecture described above, but such radio planning units may be similarly applied to other architectures upon request. May be used. A more general example of the radio planning unit 1300 is shown in FIG. In the figure, the UE, platform (or other device) includes radio hardware 1302, radio planner 1300, such as RAT module 1 1304, RAT module 2 1306, RAT module 3 1308 and RAT module 4 1310. A plurality of RAT modules. According to an exemplary embodiment, if access to a radio is granted to a particular RAT module, the RAT module may be configured to either radio via either the radio planner 1300 or a separate path, depending on the implementation. Can be used.

  According to an exemplary embodiment, for some usage patterns, the priority changes dynamically. For example, the request that follows the rejected RAT / function / request is given high priority (ie, is more likely to be assigned), and the request that follows the assigned RAT / function / request. Is given a low priority (ie, less likely to be assigned). Such a scheme applies to all or only some requests, depending on the implementation. This representative approach improves the fairness of radio time allocation among multiple RAT modules.

  According to an exemplary embodiment, for some usage scenarios, the radio activity needs to be performed at a specific time. For example, PCH reception is performed only when the network sends a PCH message. However, the measurement does not have to be performed at a specific time, and the wireless use by the measurement is dynamic in the sense that the time can be moved. Therefore, for example, when a static reservation such as PCH reception conflicts with a dynamic reservation, the dynamic reservation can be moved until no conflict occurs.

  According to an exemplary embodiment, therefore, each request is static or dynamic. Static means that the wireless access is for a specific time and a specific period. Examples of static requests include when it is necessary to read the paging channel, or when it is necessary to perform specific measurements that can only be performed at times when the corresponding signaling takes place in the network. For example, a dynamic request means that wireless access is required for a specific period at some point, or for a specific period at a specific time interval. Examples of dynamic requests include when it is necessary to perform specific measurements that can be made at any time or at appropriate regular time intervals.

  According to an exemplary embodiment, the radio planner 1300 may determine that contention is between two or more dynamic requests or between a static request and one or more dynamic requests, for example. Allocate time to dynamic requests so that they are resolved at least at some point. In addition to essentially preventing radio access contention, the radio planner can improve radio usage efficiency. By recognizing all radio activity, the radio planner 1300 may move the dynamic reservation closer to the static reservation to minimize the time that the radio is on. Further, the radio planning unit 1300 may specify the position of radio time that is not being used in order to maximize the radio usage.

  For example, the radio planning unit 1300 allocates time to the dynamic request so that the allocated radio usage time is summarized as much as possible. As a result of such a technique, the period during which no radio is allocated becomes longer. During such a period, the radio is turned off or enters a low power consumption mode, in which case power is saved. In another example, if the active RAT is in discontinuous reception (DRX) mode, the radio usage time of the other RAT is immediately after (or immediately before) the radio usage of the active RAT, eg, the measurement time of the other RAT. Are scheduled in correlation with the DRX cycle.

  According to an exemplary embodiment, the radio is turned off or enters a low power consumption mode even if the time allocated for radio use is further scattered. However, switching between wireless off / on or wireless low power mode requires some time. Usually, this switching also consumes power. Therefore, the fewer on / off switching, the shorter the overhead time required and the lower the power consumption.

  According to an exemplary embodiment, if the radio planner 1300 can determine radio usage, for example, different usage patterns for combining PCH and measurement need not be hard-coded. Instead, the PCH and measurement can be performed individually and can be changed independently. The radio planning unit 1300 ensures that they do not compete by placing measurement reservations in radio times that are not in use.

  According to an exemplary embodiment, different RATs 1304-1310 modules or procedures result in radio usage time because the radio planner 1300 handles all such issues and each RAT interfaces only with the radio planner. Do not recognize each other at all. The radio planning unit 1300 does not need to know details of different RATs. The radio planner 1300 receives the request (possibly in combination with corresponding priority and / or dynamic / static information) and allocates radio access accordingly.

  The exemplary embodiments described in this specification allow new RATs to be added to the architecture / implementation without having to adapt existing RATs. Wireless contention is handled effectively and fairly. For example, a RAT / function that has been denied access to the radio is likely to be allowed to make subsequent requests due to a change in priority. Signal transmission between blocks is very simple compared to signal transmission between blocks in a conventional multi-RAT device. Each RAT transmits a request only to the radio planning unit 1300 and obtains an assignment or rejection from the radio planning unit 1300. Signal transmission between RAT modules for managing radio time is not required. Power efficiency is improved. For example, the power consumption of the UE decreases due to at least one of an improvement in the efficiency of signal transmission and a decrease in the signal transmission. In addition, the radio planning unit 1300 can schedule the time when the radio is on as much as possible, and as a result, can similarly schedule the time when the radio is off. Therefore, it is necessary to frequently turn on / off the radio. Without power consumption.

  An exemplary method for avoiding contention between resource requests for multiple radio access technology (RAT) modules is shown in FIG. In the figure, a priority is assigned to a radio time reservation request in step 1400, a radio time reservation request including the priority is transmitted in step 1402 (for example, to the radio planning unit 1300), and a radio time reservation in step 1404. Either a permit or a reject for the request is received. According to one embodiment, the radio time is specified using a unified time reference in the radio time reservation request.

  Another exemplary method for avoiding contention between resource requests for multiple radio access technology (RAT) modules is shown in FIG. In the figure, in step 1500, a radio time reservation request including the priority of radio time reservation requests is received at the radio planning function. In step 1502, permission or denial of the radio time reservation request is determined, and in step 1504, a unified time reference for the radio time reservation request is assigned when the radio time reservation request is allowed. Send either permit or deny based on determining whether the request is allowed or denied.

  The representative embodiments described above are intended to be illustrative and not restrictive in all respects of the invention. Accordingly, the present invention is capable of many variations in detailed implementation that can be derived from the description contained in this specification by those skilled in the art. No element, operation or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used in this specification, the singular forms are intended to include the plural forms.

Claims (12)

A multi-RAT platform configured to enable communication with a plurality of different radio access technologies (RATs) using a plurality of procedures associated with a plurality of transmit / receive processing functions;
The plurality of procedures are realized by at least one of hardware and software, and realize the plurality of transmission / reception processing functions via a plurality of functional units (FU) that execute predetermined operations,
The plurality of FUs are:
Executed before the predetermined operation, and
(A) a storage location for fetching data for operation or a parameter associated with the predetermined operation executed by the FU; and (b) a storage location for storing data as a result of the predetermined operation. A pre-order specifying at least one of
A post-command specifying a type of message to be executed after the predetermined operation and output after the predetermined operation;
Configured set of a plurality of functional units descriptors add at least one a predetermined operation performed by the FU (FUD),
Each FUD includes first information associated with one or more storage locations used by the associated FU, and second information associated with one or more messages that the associated FU transmits after processing the message; , And third information relating to parameters for setting up the relevant FU .   Each of the plurality of FUs includes an input port unit that receives a first message, a functional unit unit that processes the first message, a processing of the first message, and a type of the message indicated by each FUD. The apparatus according to claim 1, further comprising: an output port unit that transmits the second message based on the message. Wherein the plurality of FU Apparatus according to claim 1 or 2, characterized in sequential that the trigger is provided to transmit and receive processing functions. The apparatus according to any one of claims 1 to 3 , further comprising a resource manager configured to allocate hardware and software resources to a plurality of sessions associated with the plurality of FUs. One of the plurality of FUs is a wireless FU to be inserted into a chain of a plurality of FUs for executing a transmission / reception processing function related to using a radio, or a transmission / reception process related to generating a timer signal A timer FU inserted into a chain of a plurality of FUs for executing a function, or an interface FU inserted into a chain of a plurality of FUs for executing a transmission / reception processing function related to signaling to an upper layer apparatus according to any one of claims 1 to 4, characterized in that. Multi-RAT radio communication apparatus having an apparatus according to any one of claims 1 to 5. A method for realizing a plurality of wireless communication functions in a distributed manner, the method comprising:
Generating a plurality of procedures for performing a plurality of transmission / reception processing functions enabling communication with a plurality of different radio access technologies (RATs);
Realizing the plurality of transmission / reception processing functions via a plurality of functional units (FU) that are realized by at least one of hardware and software and execute a predetermined operation;
Is performed before the predetermined operation, and, (a) data for the operation or a memory location to fetch the parameters associated with the predetermined operation to be executed by the FU, (b) of the predetermined A prior instruction that specifies at least one of storage locations for storing data that is the result of an operation, and a type of message that is executed after the predetermined operation and is output after the execution of the predetermined operation of the post instruction to, possess a step of configuration of the plurality of FU by a plurality of functional units descriptors add at least one a predetermined operation more is performed FU (FUD),
Each FUD includes first information associated with one or more storage locations used by the associated FU, and second information associated with one or more messages that the associated FU transmits after processing the message; And third information relating to parameters for setup of the relevant FU . Each of the plurality of FUs includes an input port unit that receives a first message, a functional unit unit that processes the first message, a processing of the first message, and a type of the message indicated by each FUD. The method according to claim 7 , further comprising: an output port unit that transmits a second message based on the message. 9. The method according to claim 7 , further comprising the step of sequentially triggering the plurality of FUs so as to execute a transmission / reception processing function. 10. The method according to claim 7 , further comprising the step of allocating hardware and software resources to a plurality of sessions related to the plurality of FUs via a resource manager. One of the plurality of FUs is a wireless FU to be inserted into a chain of a plurality of FUs for executing a transmission / reception processing function related to using a radio, or a transmission / reception process related to generating a timer signal A timer FU inserted into a chain of a plurality of FUs for executing a function, or an interface FU inserted into a chain of a plurality of FUs for executing a transmission / reception processing function related to signaling to an upper layer 11. A method according to any one of claims 7 to 10 , characterized in that it is. When executed by a computer or processor,
Generating a plurality of procedures for performing a plurality of transmission / reception processing functions enabling communication with a plurality of different radio access technologies (RATs);
Realizing the plurality of transmission / reception processing functions via a plurality of functional units (FU) that are realized by at least one of hardware and software and execute a predetermined operation;
Is performed before the predetermined operation, and, (a) data for the operation or a memory location to fetch the parameters associated with the predetermined operation to be executed by the FU, (b) of the predetermined A prior instruction that specifies at least one of storage locations for storing data that is the result of an operation, and a type of message that is executed after the predetermined operation and is output after the execution of the predetermined operation to post instruction and among the plurality of programs executes a step of configuration settings FU instructions by a plurality of functional units descriptors to be added to the predetermined operation more runs (FUD) at least one to FU seen including,
Each FUD includes first information associated with one or more storage locations used by the associated FU, and second information associated with one or more messages that the associated FU transmits after processing the message; , the program characterized in that it comprises a third information relating to the parameters for setting up the FU to the relationship.

Images