Patent Description:
The following documents are relevant: <NPL>; <NPL>, <CIT> which discusses a network for updating firmware and/or software in wireless communication devices, and <NPL>.

Claimed subject matter is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when read with the accompanying drawings in which:.

It will be appreciated that for simplicity and/or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of claimed subject matter. It will, however, be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and/or circuits have not been described in detail.

Referring now to <FIG>, a diagram of a system to reconfigure a reconfigurable mobile device in accordance with one or more embodiments will be discussed. As shown in <FIG>, system <NUM> may include a reconfigurable mobile device (MD) <NUM> or user equipment (UE). The terms mobile device and user equipment may be utilized interchangeably, and the scope of the claimed subject matter is not limited in this respect. In order to provide reconfiguration of the reconfigurable MD <NUM>, system <NUM> may utilize RadioApps comprising applications, or Radio Applications, that extend or modify existing radio features of the reconfigurable MD <NUM> and further may provide solutions for technical, certification, and/or security requirements for the reconfigurable MD <NUM>. In one or more embodiments, RadioApps may be used to optimize the operation of a reconfigurable MD <NUM> in general or for usage in a specific market with special needs. For example, RadioApps may be used to optimize the operation of a reconfigurable MD <NUM> in response to the introduction of new features on the network side as such features evolve in ongoing future releases of the Third Generation Partnership Project (3GPP) standard. In other embodiments, an optimum configuration may be identified to meet power efficiency, for example new power-efficient modulation and coding schemes, predictable Quality of Service (QoS) and/or other requirements. In another example, RadioApps may be utilized to add new mechanisms that take into account specific characteristics of the usage environment such as specific interference properties in a factory environment in which reconfigurable MD <NUM> is deployed. In yet another example, proprietary features and/or extensions may be implemented that are not yet part of a 3GPP standard, for example device-to-device communication. In some embodiments, entire radio access technologies (RATs) may be replaced in a reconfigurable MD <NUM> where sufficient computational resources are available. The above are merely some examples of how RadioApps may be used to reconfigure a reconfigurable MD <NUM>, and the scope of the claimed subject matter is not limited in these respects.

As shown in <FIG>, a reconfigurable MD <NUM> may send a request to a RadioApp store server <NUM>. One or more RadioApps may be provided to the RadioApp store server <NUM> by a Radio Application Provider <NUM> which may send one or more Radio Application Packages <NUM> containing one or more RadioApps via a Radio Programming Interface (RPI) <NUM>. The RadioApp store server <NUM> may then transmit one or more RadioApps to reconfigurable MD <NUM> via download <NUM>.

In one or more embodiments, reconfigurable MD <NUM> may execute the Radio Application (RA) code consisting of various functional blocks of which the granularities might be all different depending upon hardware platform vendors and/or depending on the features provided by mobile device manufacturers. The manufacturer and/or a third-party software manufacturer may develop the entire or partial RA code using standard programming interfaces. A modular software approach may be utilized in order to maximize the reusability of software components. Furthermore, the evolution of various radio access technologies (RATs) may be supported by adding and/or replacing functional blocks on a given hardware platform of reconfigurable MD <NUM>.

In one or more embodiments, the architecture of reconfigurable MD <NUM> may include a Communication Services Layer (CSL) <NUM>, a Radio Control Framework (RCF) <NUM>, a Radio Platform (RP) <NUM>, and a Unified Radio Application (URA) <NUM>. The Communication Services Layer <NUM> provides functionalities for installation, de-installation, selection, and/or configuration of software components and the management of the data flows. Communication Services Layer <NUM> may include functionalities such as an Administrator <NUM>, a Mobility Policy Manager <NUM>, a Networking Stack <NUM>, and a Monitor <NUM>. The Radio Control Framework <NUM> manages the software execution through a number of functionalities. The Radio Control Framework <NUM> may include functionalities such as a Configuration Manager <NUM>, a Radio Connection Manager <NUM>, a Multiradio Controller <NUM>, a Resource Manager <NUM>, and a Flow Controller <NUM>. The Radio Platform <NUM> may include a Baseband processor and other circuits <NUM>, and a radio-frequency (RF) Transceiver <NUM>. The Unified Radio Application <NUM> represents the software downloaded and installed on the target Radio Platform <NUM>. The Radio Control Framework (RCF) <NUM> may control execution of the Unified Radio Application <NUM>, although the scope of the claimed subject matter is not limited in this respect.

In one or more embodiments, the Unified Radio Application <NUM> is the software component or components of one or more Radio Access Technologies (RATs) implemented by RF Transceiver <NUM> such as WiFi operating in accordance with an Institute of Electrical and Electronics Engineers (IEEE) <NUM> standard or the like, Bluetooth operating in accordance with a Bluetooth Special Interest Group (SIG) standard, or cellular operating in accordance with a Third Generation Partnership Project (3GPP) or a European Telecommunication Standards Institute (ETSI) standard, an so on, although the scope of the claimed subject matter is no limited in this respect. The software, instructions, or code of Unified Radio Application <NUM> may be executed on any resources of the reconfigurable MD <NUM>, for example on a baseband processor <NUM>, a field- programmable gate array (FPGA), a digital signal processor (DSP), and so on, and the scope of the claimed subject matter is not limited in this respect.

In one or more embodiments, system <NUM> and/or reconfigurable MD <NUM> may utilize four interfaces to implement software defined radio configuration and/or reconfiguration of reconfigurable MD <NUM>. A Multiradio Interface (MURI) <NUM> may be used for interfacing the Communication Services Layer <NUM> and Radio Control Framework <NUM>. In particular, as discussed in further detail herein, MURI <NUM> of reconfigurable MD <NUM> may be adapted to provide a mechanism to implement software updates, while maintaining old configuration data, without requiring full de-installation and installation of a given software component. A Unified Radio Application Interface (URAI) <NUM> may be utilized to interface Radio Control Framework <NUM> and Unified Radio Application <NUM>. A Reconfigurable Radio Frequency Interface (RRFI) <NUM> may be utilized to interface the United Radio Application (<NUM>) and the RF Transceiver <NUM>. In addition, the Radio Programming Interface (RPI) <NUM> may be implemented to allow for independent and uniform production of Radio Applications. In general, the chipset of the reconfigurable MS <NUM> exists below the dotted line of MURI <NUM>, and the chipset interface exists above the dotted line of MURI <NUM>, although the scope of the claimed subject matter is not limited in this respect. An example of the interconnection between MURI <NUM> and CSL <NUM> and RCF <NUM> is shown in and described with respect to <FIG>, below.

Referring now to <FIG>, a diagram of a multiradio interface (MURI) of a reconfigurable mobile device in accordance with one or more embodiments will be discussed. <FIG> illustrates how Control Services Layer (CSL) <NUM> and Radio Control Framework (RCF) <NUM> interact with each other using Multiradio Interface (MURI) <NUM>. MURI <NUM> and RCF <NUM> may be implemented on a Radio Computer <NUM> of reconfigurable mobile device (MD) <NUM>. In one or more embodiments, reconfigurable MD <NUM> may include various services to provide interconnection between CSL <NUM> and RCF <NUM> via MURI <NUM>. Such services may include Administrative Services <NUM>, Access Control Services <NUM>, and/or Data Flow Services <NUM>. In one or more embodiments, the Administrative Services <NUM> may be extended to provide software updates for reconfigurable MD <NUM> without losing any parameters of a previous configuration, or while maintaining at least a subset of parameters of a previous configuration. Administrative Services <NUM> are used by a device configuration application such as Administrator <NUM> of CSL <NUM> to install and/or uninstall a new Unified Radio Application (URA) <NUM> into or from the reconfigurable MD <NUM> and/or to create or delete an instance of the URA <NUM>. Installation and/or loading of the URA <NUM> may take place at start-up time of the reconfigurable MD <NUM> to set up the network connection and/or during run-time whenever reconfiguration of available URAs <NUM> is needed. In some embodiments, MURI <NUM> does not make any assumption on how and/or when the reconfigurable MD <NUM> will detect a need for the reconfiguration. Extension of the Administrative Services of MURI <NUM> to include software update functionality is shown in and described with respect to <FIG>, below.

Referring now to <FIG>, a diagram of a Unified Modeling Language (UML) diagram for MURI Administrative Services that includes a software update functionality in accordance with one or more embodiments will be discussed. In one or more embodiments, Multiradio Interface (MURI) <NUM> includes an interface <NUM> to the MURI (IMURI), an interface "IAdminstrativeServices" <NUM> to the Administrative Services <NUM>, an interface "IAccessControlServices" <NUM> to the Access Control Services <NUM>, and an interface "IDataFlowServices" <NUM> to the Data Flow Services <NUM>. The interface "IAdminstrativeServices" <NUM> to the Administrative Services <NUM> may be modified to include software update functionality by adding "UpdateRadioApp" +updateRadioApps():INTEGER. Furthermore, Chapter <NUM> of European Telecommunications Standards Institute (ETSI) European Norm (EN) <NUM><NUM>-<NUM> may be modified as follows to include the following Updating instance of URA as shown in underlining below.

Table <NUM> describes an overview on Administrative Services which are associated with Administrator. Class definition and related operations are described in clause <NUM>.

The interfaces for Administrative Services are used to transmit the following messages:.

Furthermore, Section <NUM> of ETSI EN <NUM><NUM>-<NUM> may be modified as shown with underlining as follows.

The interfaces for Access Control Services are used to transmit the following messages:.

In addition, in one or more embodiments, the class definitions described in Chapter <NUM> of ETSI EN <NUM><NUM>-<NUM> may be modified as shown in underling as follows.

Each interface class related to MURI can be defined using the template presented in clause <NUM> and in accordance with the UML® diagram of figure <NUM> which specifies the interface classes related to MURI. Tables <NUM> to <NUM> specify all the operations related to the three interface classes above described.

In accordance with one or more embodiments, the basic process to update a software component and/or a radio application of reconfigurable MD <NUM> may be as follows. Optionally, a user equipment (UE) or reconfigurable MD <NUM> receives an announcement of a new Software Component. The UE may accept or reject the new Software Component or may be forced to install the new software component replacing a previously installed version. A new Software Component, meant for replacing a previous version of the same software component, is downloaded to a target UE, for example through a peer-to-peer connection providing an update of a Software Component for a specific user only, through a point-to-multipoint connection providing an update of a Software Component for a group of specific users, or through a broadcast connection providing an update of a Software Component for all user. In some embodiments, a mixture of peer-to-peer and point-to-multipoint may be implemented, although the scope of the claimed subject matter is not limited in this respect.

The target UE then verifies if the Software Component is valid and authorized for installation. If the Software Component is identified to be not valid or no authorization for installation is given, then the procedure may be abandoned, and the existing version of the Software Component is kept. Alternatively, a verification procedure may occur before the downloading of a new Software Component such that Software Components are able to be downloaded to the target UE only if such Software Components qualify for being installed and/or used as an update of an existing Software Component. The updating procedure then may be initiated, replacing the previous version of the Software Component with the newly downloaded version of the new Software Component.

In one or more embodiments, the "updateRadioApps" operation may be applied to activate active URA Instances and to deactivate inactive URA Instances. In case that the URA Instance is active, the "updateRadioApps" service typically will first deactivate the concerned URA Instance, recover the configuration parameters, de-install the URA Instance, install the new RadioApp and create a new URA Instance, apply the previously saved configuration parameters to the new URA Instance such that the configuration remains and activates the updates URA Instance. It is also possible that the update service will only retain a sub-set of the configuration parameters or none of the configuration parameters, although the scope of the claimed subject matter is not limited in this respect.

It should be noted that ETSI European Norm (EN) <NUM><NUM> describes a SW Reconfiguration architecture that includes four distinct interfaces that are defined in EN <NUM><NUM>-<NUM>, EN <NUM><NUM>-<NUM>, EN <NUM><NUM>-<NUM>, and EN <NUM><NUM>-<NUM> respectively. In accordance with one or more embodiments, EN <NUM><NUM>-<NUM> has been modified as discussed herein to provide the ability to update the software via a "Software Update" function of a reconfigurable MD <NUM> while preserving the parameters, or at least a subset of the parameters, of a prior software configuration. It should be further noted that these standards described in EN <NUM><NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> also may be utilized in automotive applications such as autonomous vehicles. For example, the ability to provide a software update for a reconfigurable mobile device <NUM> as described herein may be applicable to the replacement of one or more Radio Access Technology (RAT) sub-components of a Dedicated Short Range Communications (DSRC) such as defined by IEEE <NUM>. 11p for vehicular environments, for Cellular Vehicle-to-Everything (C-V2X) based on Third Generation Partnership Project (3GPP) standards such as a Long-Term Evolution (LTE) standard or the link, for example to update the code of a Unified Radio Application <NUM> in the case that a vulnerability is discovered. It should be noted, however, that these are merely example applications of the ability to provide a software update to a reconfigurable MD <NUM>, and the scope of the claimed subject matter is not limited in these respects.

Referring now <FIG>, an architecture of a system of a network in accordance with some embodiments will be discussed. The system <NUM> is shown to include a user equipment (UE) <NUM> and a UE <NUM>. The UEs <NUM> and <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the UEs <NUM> and <NUM> can comprise an Internet of Things (IoT) UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

The UEs <NUM> and <NUM> may be configured to connect, e.g., communicatively couple, with a radio access network (RAN) <NUM> - the RAN <NUM> may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs <NUM> and <NUM> utilize connections <NUM> and <NUM>, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (<NUM>) protocol, a New Radio (NR) protocol, and the like.

Any of the radio links or interfaces described herein may operate according to any one or more of the following radio communication technologies and/or standards including but not limited to: a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology, for example Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code division multiple access <NUM> (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, Third Generation (<NUM>), Circuit Switched Data (CSD), High-Speed Circuit-Switched Data (HSCSD), Universal Mobile Telecommunications System (Third Generation) (UMTS (<NUM>)), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), High Speed Packet Access Plus (HSPA+), Universal Mobile Telecommunications System-Time-Division Duplex (UMTS-TDD), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Release <NUM> (Pre-4th Generation) (3GPP Rel. <NUM> (Pre-<NUM>)), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>) , 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>) and subsequent Releases (such as Rel. <NUM>, Rel. <NUM>, etc.), 3GPP <NUM>, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4th Generation) (LTE Advanced (<NUM>)), cdmaOne (<NUM>), Code division multiple access <NUM> (Third generation) (CDMA2000 (<NUM>)), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1st Generation) (AMPS (<NUM>)), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Digital AMPS (2nd Generation) (D-AMPS (<NUM>)), Push-to-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D), Public Automated Land Mobile (Autotel/PALM), ARP (Finnish for Autoradiopuhelin, "car radio phone"), NMT (Nordic Mobile Telephony), High capacity version of NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), also referred to as also referred to as 3GPP Generic Access Network, or GAN standard), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig) standard, mmWave standards in general (wireless systems operating at <NUM>-<NUM> and above such as WiGig, IEEE <NUM>. 11ad, IEEE <NUM>. 11ay, etc.), technologies operating above <NUM> and THz bands, (3GPP/LTE based or IEEE <NUM>. 11p and other) Vehicle-to-Vehicle (V2V) and Vehicle-to-X (V2X) and Vehicle-to-Infrastructure (V2I) and Infrastructure-to-Vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (Dedicated Short Range Communications) communication systems such as Intelligent-Transport-Systems and others (typically operating in <NUM> to <NUM>), the European ITS-G5 system (i.e. the European flavor of IEEE <NUM>. 11p based DSRC, including ITS-G5A (i.e., Operation of ITS-G5 in European ITS frequency bands dedicated to ITS for safety re-lated applications in the frequency range <NUM>,<NUM> to <NUM>,<NUM>), ITS-G5B (i.e., Operation in European ITS frequency bands dedicated to ITS non- safety applications in the frequency range <NUM>,<NUM> to <NUM>,<NUM>), ITS-G5C (i.e., Operation of ITS applications in the frequency range <NUM>,<NUM> to <NUM>,<NUM>)), DSRC in Japan in the <NUM> band (including <NUM> to <NUM>) etc..

Aspects described herein can be used in the context of any spectrum management scheme including dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as LSA = Licensed Shared Access in <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and further frequencies and SAS = Spectrum Access System in <NUM>-<NUM> and further frequencies). Applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum as well as other types of spectrum/bands, such as bands with national allocation (including <NUM> - <NUM>, <NUM>-<NUM> (note: allocated for example in US (FCC Part <NUM>)), <NUM>-<NUM> (note: allocated for example in European Union (ETSI EN <NUM><NUM>)), <NUM>-<NUM> (note: allocated for example in Japan), <NUM>-<NUM> (note: allocated for example in South Korea), <NUM>-<NUM> and <NUM>-<NUM> (note: allocated for example in China), <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM>-<NUM> (note: it is an ISM band with global availability and it is used by Wi-Fi technology family (11b/g/n/ax) and also by Bluetooth), <NUM> - <NUM>, <NUM>-<NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM>-<NUM> (note: allocated for example in the US for Citizen Broadband Radio Service), <NUM>-<NUM> and <NUM>-<NUM> and <NUM>-<NUM> and <NUM>-<NUM> bands (note: allocated for example in the US (FCC part <NUM>), consists four U-NII bands in total <NUM> spectrum), <NUM>-<NUM> (note: allocated for example in EU (ETSI EN <NUM><NUM>)), <NUM>-<NUM> (note: allocated for example in South Korea, <NUM>-<NUM> and <NUM>-<NUM> band (note: under consideration in US and EU, respectively. Next generation Wi-Fi system is expected to include the <NUM> spectrum as operating band but it is noted that, as of December <NUM>, Wi-Fi system is not yet allowed in this band. Regulation is expected to be finished in <NUM>-<NUM> time frame), IMT-advanced spectrum, IMT-<NUM> spectrum (expected to include <NUM>-<NUM>, <NUM> bands, <NUM> bands, bands within the <NUM>-<NUM> range, etc.), spectrum made available under FCC's "Spectrum Frontier" <NUM> initiative (including <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM>, <NUM> - <NUM> and <NUM> - <NUM>, etc), the ITS (Intelligent Transport Systems) band of <NUM> (typically <NUM>-<NUM>) and <NUM>-<NUM>, bands currently allocated to WiGig such as WiGig Band <NUM> (<NUM>-<NUM>), WiGig Band <NUM> (<NUM>-<NUM>) and WiGig Band <NUM> (<NUM>-<NUM>) and WiGig Band <NUM> (<NUM>-<NUM>), <NUM>-<NUM>/<NUM> (note: this band has near-global designation for Multi-Gigabit Wireless Systems (MGWS)/WiGig. In US (FCC part <NUM>) allocates total <NUM> spectrum, while EU (ETSI EN <NUM><NUM> and ETSI EN <NUM><NUM>-<NUM> for fixed P2P) allocates total <NUM> spectrum), the <NUM> - <NUM> band, any band between <NUM> and <NUM>, bands currently allocated to automotive radar applications such as <NUM>-<NUM>, and future bands including <NUM>-<NUM> and above. Furthermore, the scheme can be used on a secondary basis on bands such as the TV White Space bands (typically below <NUM>) where in particular the <NUM> and <NUM> bands are promising candidates. Besides cellular applications, specific applications for vertical markets may be addressed such as PMSE (Program Making and Special Events), medical, health, surgery, automotive, low-latency, drones, etc. applications.

Aspects described herein can also implement a hierarchical application of the scheme is possible, e.g. by introducing a hierarchical prioritization of usage for different types of users (e.g., low/medium/high priority, etc.), based on a prioritized access to the spectrum e.g. with highest priority to tier-<NUM> users, followed by tier-<NUM>, then tier-<NUM>, etc. users, etc..

Aspects described herein can also be applied to different Single Carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.) and in particular 3GPP NR (New Radio) by allocating the OFDM carrier data bit vectors to the corresponding symbol resources.

Some of the features in this document are defined for the network side, such as Access Points, eNodeBs, New Radio (NR) or next generation Node Bs (gNodeB or gNB - note that this term is typically used in the context of 3GPP fifth generation (<NUM>) communication systems), etc. Still, a User Equipment (UE) may take this role as well and act as an Access Points, eNodeBs, gNodeBs, etc. i.e., some or all features defined for network equipment may be implemented by a UE.

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

The RAN <NUM> is shown to be communicatively coupled to a core network (CN) <NUM> -via an S1 interface <NUM>. In embodiments, the CN <NUM> may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface <NUM> is split into two parts: the S1-U interface <NUM>, which carries traffic data between the RAN nodes <NUM> and <NUM> and the serving gateway (S-GW) <NUM>, and the S1-mobility management entity (MME) interface <NUM>, which is a signaling interface between the RAN nodes <NUM> and <NUM> and MMEs <NUM>.

Referring now to <FIG>, example components of a device in accordance with some embodiments will be discussed. In some embodiments, the device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, one or more antennas <NUM>, and power management circuitry (PMC) <NUM> coupled together at least as shown. The components of the illustrated device <NUM> may be included in a UE or a RAN node. In some embodiments, the device <NUM> may include less elements (e.g., a RAN node may not utilize application circuitry <NUM>, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The baseband circuitry <NUM> may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a third generation (<NUM>) baseband processor 504A, a fourth generation (<NUM>) baseband processor 504B, a fifth generation (<NUM>) baseband processor 504C, or other baseband processor(s) 504D for other existing generations, generations in development or to be developed in the future (e.g., second generation (<NUM>), sixth generation (<NUM>), etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 504A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. In other embodiments, some or all of the functionality of baseband processors 504A-D may be included in modules stored in the memory <NUM> and executed via a Central Processing Unit (CPU) 504E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include one or more audio digital signal processor(s) (DSP) 504F. The audio DSP(s) 504F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on a chip (SOC).

RF circuitry <NUM> may include a receive signal path which may include circuitry to downconvert RF signals received from the FEM circuitry <NUM> and provide baseband signals to the baseband circuitry <NUM>.

In some embodiments, the receive signal path of the RF circuitry <NUM> may include mixer circuitry 506a, amplifier circuitry 506b and filter circuitry 506c. In some embodiments, the transmit signal path of the RF circuitry <NUM> may include filter circuitry 506c and mixer circuitry 506a. RF circuitry <NUM> may also include synthesizer circuitry 506d for synthesizing a frequency for use by the mixer circuitry 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 506a of the receive signal path may be configured to downconvert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 506d. The amplifier circuitry 506b may be configured to amplify the down-converted signals and the filter circuitry 506c may be a low-pass filter (LPF) or bandpass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 506a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 506a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 506d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 506c.

In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the synthesizer circuitry 506d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 506d may be configured to synthesize an output frequency for use by the mixer circuitry 506a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 506d may be a fractional N/N+<NUM> synthesizer.

In some embodiments, frequency input may be provided by a voltage-controlled oscillator (VCO), although that is not a requirement.

Synthesizer circuitry 506d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 506d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

While <FIG> shows the PMC <NUM> coupled only with the baseband circuitry <NUM>. However, in other embodiments, the PMC <NUM><NUM> may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry <NUM>, RF circuitry <NUM>, or FEM <NUM>.

If there is no data traffic activity for an extended period of time, then the device <NUM> may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device <NUM> goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device <NUM> may not receive data in this state, in order to receive data, it must transition back to RRC_Connected state.

Referring now to <FIG>, example interfaces of baseband circuitry in accordance with some embodiments will be discussed. As discussed above, the baseband circuitry <NUM> of <FIG> may comprise processors 504A-504E and a memory <NUM> utilized by said processors. Each of the processors 504A-504E may include a memory interface, 604A-604E, respectively, to send/receive data to/from the memory <NUM>.

In the description herein and/or claims, the terms coupled and/or connected, along with their derivatives, may be used. In particular embodiments, connected may be used to indicate that two or more elements are in direct physical and/or electrical contact with each other. Coupled may mean that two or more elements are in direct physical and/or electrical contact. Coupled, however, may also mean that two or more elements may not be in direct contact with each other, but yet may still cooperate and/or interact with each other. For example, "coupled" may mean that two or more elements do not contact each other but are indirectly joined together via another element or intermediate elements. Finally, the terms "on," "overlying," and "over" may be used in the following description and claims. "On," "overlying," and "over" may be used to indicate that two or more elements are in direct physical contact with each other. It should be noted, however, that "over" may also mean that two or more elements are not in direct contact with each other. For example, "over" may mean that one element is above another element but not contact each other and may have another element or elements in between the two elements. Furthermore, the term "and/or" may mean "and", it may mean "or", it may mean "exclusive-or", it may mean "one", it may mean "some, but not all", it may mean "neither", and/or it may mean "both", although the scope of claimed subject matter is not limited in this respect. In the description herein and/or claims, the terms "comprise" and "include," along with their derivatives, may be used and are intended as synonyms for each other.

Claim 1:
An apparatus of a user equipment, UE, comprising:
a memory to store a Unified Radio Application (<NUM>) and to store one or more configuration parameters for the Unified Radio Application; and
one or more baseband processors to receive a radio application update from a remote server, and to update the Unified Radio Application via a Multiradio Interface (<NUM>), MURI, "updateRadioApps" operation with the received radio application update, wherein the "updateRadioApps" operation is handled by an Administrative Services function of the MURI and comprises:
transmitting, from a communication service layer (<NUM>), CSL, to a radio control framework (<NUM>), RCF, a request of updating an instance of the Unified Radio Application:
replacing the instance of the Unified Radio Application, wherein during the replacement process, the one or more configuration parameters for the Unified Radio Application are maintained; and
transmitting, from the RCF to the CSL, a confirmation of the updating of the instance of the Unified Radio Application.