as) United States
`a2) Patent Application Publication 10) Pub. No.: US 2016/0037505 Al
` Cooklev (43) Pub. Date: Feb. 4, 2016
`
`
`
`US 20160037505A1
`
`(54) DIGITAL RADIO SYSTEM
`
`(71) Applicant: Purdue Research Foundation, West
`Lafayette, IN (US)
`
`(72)
`
`Inventor: Todor V. Cooklev, Fort Wayne, IN (US)
`
`(52) U.S. CL
`CPC wee HO4W 72/0406 (2013.01); HO4W 8/20
`(2013.01); HO4W 84/20 (2013.01)
`
`(57)
`
`ABSTRACT
`
`(21) Appl. No.: 14/815,639
`.
`Filed:
`
`Jul. 31, 2015
`
`(22)
`
`A thin radio client can include a radio frequency (RF) sub-
`system having a transmitter and/or a receiver. An interface
`can transmit and receive packets. The interface can reconfig-
`ure the transmitter in response to a received transmitter-con-
`trol packet, reconfigure the receiver in responseto a received
`oo.
`receiver-control packet, or transmit a context packet includ-
`Related U.S. Application Data
`
`(60) Provisional application No. 62/031,807, filed on Jul. ing both data ofastate ofthe transmitter and data of a state of
`31, 2014.
`the receiver. A digital back end can include an interface to
`exchange packets with an RF device. At least some of the
`received packets can specify capabilities of the RF device or
`state of the RF device. The back end can determine a control
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`HO4AW 72/04
`HO4AW 84/20
`HO4AW 8/20
`
`(2006.01)
`(2006.01)
`(2006.01)
`
`packet based on received packet(s) and on a policy governing
`behavior of the RF device, and transmit the control packet to
`the RF device. A method of operating a distributed radio
`system is described.
`
`100 u
`
` SIGNAL-
`SPECTRUM
`
`
`PROCESSING
`SENSOR
`
`CLOUD
`
`114
`SENSOR
`
`SPECTRUM
`
`Exhibit 1067
`Samsung v. Smart Mobile
`IPR2022-01249
`
`Exhibit 1067
`Samsung v. Smart Mobile
`IPR2022-01249
`
`1
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 1 of 8
`
`US 2016/0037505 Al
`
` SIGNAL-
`PROCESSING
`
`
`
`102
`
`X
`
`222(1)~
`
`216
`
`REAL-TIME KERNEL
`
`114
`CLOUD
` 220.
`222(N)
`APPLICATION1
`APPLICATION
`212
`
`
`DRIVERS
`DIGITAL | USER |214
`HARDWARE
`ie)
`
`
`
`:
`
` ANTENNA te
`
`SYSTEM
`CONVERT
`
`DFE
`
`FIG. 2
`
`2
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 2 of 8
`
`US 2016/0037505 A1
`
`POE
`
`c0e
`
`90€
`
`Ole
`
`cSé
`
`Ose
`
`PSE
`
`TOYULNOD
`
`LAyOVd
`
`YAGOONA
`
`TYNOIS
`
`LAyOVd
`
`YAGOONA
`
`TYNOIS
`
`LAV
`
`u34d004d
`
`YaSYVd
`
`LX4LNO9
`
`LAYOVd
`
`u34d004d
`
`
`
`c&&
`
`cle
`
`FYVMGYVHTVLIDIG
`
`YIGOONTYad
`
`LaWOVdYSIaNdNY
`
`TyNals|}9e&YALYIANOONMOG
`
` LXALNO9|vEE La0vd[7ya0030|.L3yOvd||TOLNOD
`YIGOINA
`Y3d0940
`YAGOONA
`YaSavd
`4qIS-4sa
`AGIS-4y
`TYNOIS
`B08PLE9LESLE
`
`TOYLNOD||TOYLNODTOYLNOD
`nevee
`
`440oVvdYalslidNV
`MSMSMS
`MS_|rre
`
`ONIXA1dNGWNNGINY
`OcévOL
`
`€Dd
`
`YALYFANOIdN
`
`Yatds
`
`X00€
`
`TOYLNOD
`
`8EE
`
`TOYLNOD
`
`Sd9
`
`WALSAS
`
`0ee
`
`3
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 3 of 8
`
`US 2016/0037505 A1
`
`#IGOONT
`
`cO0E
`
`CLV
`
`ble
`
`LELG
`
`OLbELG
`
`TVNOIS
`
`LAMOVd
`
`4300940
`
`TOYLNODMS|FIOYLNOOMS|FIOYLNOOMS
`
`U3FdVSH
`
`6GIWV3uLS
`
`dNVISINIL
`
`
`
`VLVGTVNOIS
`
`GVOTAVd
`
`dFTIVELL
`
`VLVO
`
`LAMOVd
`
`TOULNOD
`
`TOYLNOD
`
`OVG
`
`YALYFANODdN
`
`LAyoVd
`
`LAYOVd
`
`vO
`
`VLIVOVLIN
`
`VIVOVLIN
`
`ALVYFIdWVS
`
`AONANODASFa
`TOYLNOD
`
`YFHLO
`
`YFHLO
`
`LaMOVd
`
`0L1G CLE
`
`¥34d0950|SONLLLISJUVMGHVHOLNOLLVISNVUL
`
`4
`
`
`
`
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 4 of 8
`
`US 2016/0037505 A1
`
`/NOISSAYdNOD
`
`
`
`LAMIVdTYNOIS
`
`Y3AdOONA
`
`
`
` Gnot9YICOONA
`
`00SPOL
`
`ONISSFOOUdLAMOVd
`
`
`
`“TVNOISNOISNALX4
`
`dsd1V907
`
`LAMOVd
`
`Y3AdOONA
`
`VIVGVLAW TOULNODMS|
`
`
`
`FIOYLNODMS||IOYLNODMS
`
`S‘Sl
`
`5
`
`
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 5 of 8
`
`US 2016/0037505 Al
`
`PAIRED
`CONTROL PACKET ~«——»
`
`HEADER
`
`STREAM ID: 9
`REF POINT: 1
`RF FREQUENCY
`
`610
`
`DATA PACKET
`
`HEADER
`
`STREAMID: 9
`TIMESTAMP
`SIGNAL DATA
`
`612
`
`
`
`RF POWER
`
`
`600|OTHER METADATA TRAILER
`
`104
`
`604
`
`406
`9
`5 Pel
`
`602
`DIGITAL
`HARDWARE
`
`606
`
`
`TRAILER
`
`PAIRED
`CONTEXT PACKET ~—» DATA PACKET
`
`614
`
`HEADER
`
`STREAMID:5
`REF POINT:1
`RF FREQUENCY
`IF FREQUENCY
`
`OTHER METADATA
`
`HEADER
`
`STREAMID:5
`TIMESTAMP
`SIGNAL DATA
`PAYLOAD
`
`616
`
`6
`
`

`

`Feb. 4, 2016 Sheet 6 of 8
`
`US 2016/0037505 A1
`
`“TVN9IIS
`
`QINISSAIOdd
`
`
`
`YWLVGTVNOIS
`
`GVOTAVd
`
`
`
`VWLVGTWNOIS
`
`GVOTAVd
`
`Patent Application Publication GNOTO
`TVNOIS GVOTAVd
`
`WV3eLSNMOTd>
`
`“WVaedlSdn
`
`Z‘Sl
`
`PELc&L
`
`VVdTIVNOIS
`
`AQNANOFS4atINIOd43u
`
`L6GIWVAuls
`
`GVOTAVd
`
`VLVd
`AINANOZS4aLINIOd434
`
`YACVSH
`
`LSGIWVIuLls
`
`7
`
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 7 of 8
`
`US 2016/0037505 Al
`
`RECEIVE CONTEXT PACKETS FROM
`THIN RADIO CLIENTS
`
`800 ‘NM
`
`802
`
`804
`
`806
`
`THIN RADIO CLIENTS
`
`DETERMINE CONTROL PACKETS FOR
`THIN RADIO CLIENTS
`
`TRANSMIT CONTROL PACKETS TO
`
`FIG. 8
`
`8
`
`

`

`Patent Application Publication
`
`Feb. 4, 2016 Sheet 8 of 8
`
`US 2016/0037505 Al
`
`902%penennn:
`|
`DATA
`| PROCESSING
`i
`SYSTEM
`
`INTERFACE
`
`SYSTEM
`
`PROCESSOR
`
`PSere
`
` USER
`
`CODE cc
`MEMORY
`DISK
`
`941
`
`943
`
`DATA STORAGE SYSTEM
`
`FIG. 9
`
`9
`
`

`

`US 2016/0037505 Al
`
`Feb. 4, 2016
`
`DIGITAL RADIO SYSTEM
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This application is a nonprovisional application of,
`and claims priority to and the benefit of, U.S. Provisional
`Patent Application Ser. No. 62/031,807, filed Jul. 31, 2014
`and entitled “A Distributed Cloud-Based Radio Architecture
`
`and System Integrating Spectrum Monitoring and Spectrum
`Management,”the entirety ofwhichis incorporated herein by
`reference.
`
`TECHNICAL FIELD
`
`[0002] The present disclosure generally relates to control
`and operation of radio systems, and in some examples to
`spectrum monitoring and spectrum management.
`
`BACKGROUND
`
`[0003] Many wireless communication systems have been
`fielded, and many more are under development. The radio
`frequency (RF) spectrum has growing economic value to
`consumers, businesses, and governments worldwide. This
`highly valued commodity has generated such an everincreas-
`ing demandfor wireless bandwidth so that the existing pri-
`mary method of spectrum management, spectrum allocation,
`is becoming increasingly inadequate. In general, the RF spec-
`trum has three dimensions—time, frequency, and location.
`While current spectrum managementhas utilized nearly the
`entire frequency dimension,there is significant unexploited
`potential along the other dimensions. Spectrum surveys have
`shownthat muchofthe licensed spectrum is idle at any given
`time. Consequently, responses to requests for additional
`bandwidth increasingly involve sharing rather than exclusive
`allocation. The concept of spectrum sharing is simple: If one
`system does not require bandwidth at specific times, that
`bandwidth can be used by secondary systems during those
`times, providedthat the secondary systems do not cause unac-
`ceptable interference.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0004] Objects, features, and advantages ofvarious aspects
`will become more apparent when taken in conjunction with
`the following description and drawings wherein identicalref-
`erence numerals have been used, wherepossible, to designate
`identical features that are common to the figures. The
`attached drawings are for purposesofillustration and are not
`necessarily to scale.
`[0005]
`FIG. 1 shows an example cloud-based radio net-
`work.
`[0006]
`nents.
`
`FIG. 2 shows an exampleradio and related compo-
`
`FIG. 5 shows an examplereceiver andrelated com-
`
`FIG. 3 shows an example RF front end and RF-
`[0007]
`digital interface components.
`[0008]
`FIG. 4 shows an example transmitter and interface
`packets.
`[0009]
`ponents.
`FIG. 6 shows an example wireless relay and inter-
`[0010]
`face packets.
`[0011]
`FIG. 7 shows an example software-defined radio
`cloud system andinterface packets.
`[0012]
`FIG. 8 shows a flowchart of an example method for
`operating a distributed radio system.
`
`FIG. 9 shows an example data-processing system
`[0013]
`useful with various aspects.
`
`DETAILED DESCRIPTION
`
`For the purposes of promoting an understanding of
`[0014]
`the principles ofthe present disclosure, reference will now be
`made to the embodiments illustrated in the drawings, and
`specific language will be used to describe the same. It will
`nevertheless be understood that no limitation of the scope of
`this disclosure is thereby intended.
`[0015] Various aspects relate to systems and methods for
`spectrum monitoring using a distributed network of sensors
`allowing spectrum management to be integrated. Various
`aspects relate to integrating spectrum management and moni-
`toring on a large scale. While spectrum sharing is very desir-
`able, it will produce a variety of interference scenarios and
`will require accurate real time spectrum usage data.
`[0016] Existing spectrum usage data is largely based on
`one-time surveysthat have been conducted in many locations
`around the world. The technical parameters of spectrum sen-
`sors are generally well understood. Though the goals and
`technical parameters of these surveys differed, they each
`lasted for a relatively short period of time, typically used a
`single spectrum analyzer connected to a laptop computer, and
`were performedat onesite or at a single site at a time. Some
`prior schemesare based on spectrum analyzers connected to
`laptop computers. Spectrum analyzers are designed as pow-
`erful pieces of lab equipment with a human operator inter-
`preting signals in real-time. It would be inefficient to build a
`large-scale system for permanent spectrum monitoring sim-
`ply by extending prior monitoring-campaign schemes. The
`reason is that at present it is not possible to integrate data
`obtained from different spectrum sensors, with different reso-
`lution, etc. A large-scale spectrum monitoring program was
`contemplated by the Federal Communications Commission
`(FCC) at the beginning of 1970s, but subsequently aban-
`doned. Morerecently, the National Telecommunications and
`Information Agency (NTIA), which is responsible for gov-
`ernment-wide spectrum management and whichalso assigns
`spectrum to federal agencies, has been criticized that it
`merely aggregates the spectrum needsofthe different gov-
`ernmentagencies and is being incapable to ensure that spec-
`trum is being used efficiently. Additionally, the Government
`Accountability Office (GAO)hasalso foundthat the accuracy
`of agency-reported data could not be guaranteed.
`[0017]
`In2013 the President issued a Memorandum direct-
`ing NTIAto design and conduct a pilot program to monitor
`spectrum usagein real-time in select communities around the
`country. One of the goals of the monitoring is to identify
`opportunities for spectrum sharing, not only among govern-
`ment agencies, but also between government and non-gov-
`ernmentusers. The NTIA asked for input what should be the
`parameters of such a system, such as monitored frequency
`band(s), resolution bandwidth, sampling rate, dwell time,
`antennas, geographic locations, etc. and several companies
`responded.
`[0018] The responses reveal emerging consensusregarding
`several aspects. Spectrum monitoring between 30 MHz andat
`least 3 GHz, preferably 6 GHz,is needed.It is possible that in
`the future monitoring is extended to other frequency bands.
`The industry generally believes that spectrum monitoring
`should capture and store in-phase and quadrature (IQ) com-
`ponents at basebandor IF output. The IQ data should then be
`processed using fast Fourier transforms (FFTs) to obtain
`
`10
`
`10
`
`

`

`US 2016/0037505 Al
`
`Feb. 4, 2016
`
`powerspectral density. Other specialized analysis can also be
`performed on the IQ samples. Another aspect where consen-
`sus is emerging is that monitoring should start with a priori
`information provided by an accurate database of systemsthat
`are known to be operational. This database can include the
`technical parametersthat are relevant for their term of autho-
`rization, such as frequency bands, effective radiated power,
`etc. One purpose of the monitoring is to confirm that the
`known systems operate as authorized, or to provide evidence
`that they are not. Furthermore, monitoring can be used to
`identify transmitters that are not included in the database and
`are therefore presumably unlicensed. Another purpose of
`spectrum monitoring is to help determine how much ofthe
`spectrum is being used by systems that have been allocated
`parts of the spectrum and identify opportunities for spectrum
`sharing. Monitoring can also be usefulto identify interference
`issues among wireless systems. To achieve all of these goals
`monitoring has to be permanent; one-time, single-site surveys
`are no longer adequate.
`[0019] There is thus an unmetneed for a novel distributed
`system capable of sensing usage of the available spectrum
`between two or more frequency limits.
`[0020]
`FIG. 1 shows an example cloud-based network and
`system of spectrum sensors useful, e.g., for spectrum moni-
`toring. The term “cloud”is used herein to indicate available
`servers and their computation power on the Internet or some
`other network. Various examples permit ontology descrip-
`tionsto be used for both spectrum management and monitor-
`ing. These ontology descriptions allow semantic techniques
`such as queries, responses, and reasoning to be used. Example
`systems disclosed herein include multiple simple, inexpen-
`sive spectrum sensors.
`[0021] Wireless signals are centered at a certain radio fre-
`quency (RF). Signal-processing operations, e.g., synchroni-
`zation and modulation, can be implemented on baseband
`signals centered at substantially zero frequency or having
`positive frequency components extending upwards from sub-
`stantially zero frequency. Therefore, receivers can down-con-
`vert from RF to baseband. Transmitters can perform the oppo-
`site process of up-conversion. The RF front end, located
`between the antenna andthe digital subsystem, can perform
`the tasks of down-conversion and up-conversion and can also
`perform filtering for frequency band selection and amplifica-
`tion.
`
`[0022] Various aspects include an RF-digital interface that
`permits the RF front end andthe digital hardware to be seam-
`lessly replaced independently of each other. Various example
`interfaces herein process a stream of data and metadata (con-
`text and control) packets. The interface describes the RF front
`end and can serve as a hardware abstraction language for the
`RFfront end. The metadata packets can be described using a
`simple ontology, such as RDF (described below), and
`exchanged among different cognitive radio platforms. Vari-
`ous terms used in the present application are given in Table 1.
`
`Term
`
`Definition
`
`TABLE1
`
`Baseband
`
`digitally modulated signal that is low-pass in nature(thatis,
`not up-converted onto an RFcarrier)
`Interpolation increasing the sampling frequency
`Decimation
`decreasing the sampling frequency
`IF
`intermediate frequency
`
`TABLE 1-continued
`
`Term
`
`Definition
`
`Down-
`conversion
`Up-
`conversion
`Waveform
`software
`Ontology
`Metadata
`
`the process ofmoving a signal’s spectrum content from
`RF to zero frequency(or to IF)
`the process ofmoving a signal’s spectrum content
`from zero to RF (or to IF)
`software that implements a radio-access technology
`a general mechanism to describe objects in a certain domain
`and therelationships between them
`data that helps interpret signals (data about data)
`
`[0023] Between, e.g., 30 MHz and 6 GHzthere are numer-
`ous wireless systems with different bandwidths, modulation
`formats, multiple-access techniques, or output powerlevels.
`There are certain bands where real-time or near real-time
`
`performanceis required, for example bands used by public-
`safety operations. Spectrum use varies widely with location
`and therefore, different monitoring systems may be neededin
`urban, suburban, rural, and remote areas. For example, mod-
`ern civilian, public-safety, and military wireless networksare
`highly heterogeneous. It is desirable for new radios, services,
`and applications to be readily incorporated, without signifi-
`cant changes elsewhere in the network. Various aspects relate
`to a languagethat can be used to describe both the capabilities
`of RF components and their current operationalstatus.
`[0024]
`FIG. 1 shows a cloud-based spectrum monitoring
`system 100 according to various aspects. Spectrum sensor
`102 is connected to antenna 104 via link 106, e.g., an RF feed
`line. Spectrum sensor 108 is connected to antenna 110 via
`link 112, e.g., an RF feed line. Spectrum sensor 102 is con-
`nected to signal-processing cloud 114 via link 116, e.g., a
`digital link as described herein. Spectrum sensor 108 is con-
`nected to cloud 114 via link 118, e.g., a digital
`link as
`described herein.
`
`Insome examples, spectrum sensors 102, 108 have
`[0025]
`a bidirectional interface with cloud 114. In some examples,
`spectrum sensors 102, 108 include analog as well as digital
`hardware. In an example spectrum monitoring system 100,
`the sensors 102, 108 can offer at least a sensing service to
`cloud 114. Other services such as modulation identification,
`and, in some cases, complete demodulation of the signal, can
`also be provided. The cloud 114 can also offer services to the
`spectrum sensors 102, 108, thin clients or third parties.
`[0026] The cloud 114 can offer the use of digital hardware
`using the infrastructure as a service (IaaS) model. Higher
`levels of service can also be offered, such as “platform as a
`service” (PaaS), where in addition to digital hardware, the
`cloud offers the use of system-level software, and “spectrum
`monitoring software as a service”, where the use of a hard-
`ware and software solution that implements spectrum moni-
`toring is offered as a service. The monitoring software can be
`implementedas a collection of interacting entities each ful-
`filling a specific role. In some examples, cloud 114 offers
`“radio software as a service”, where the software that imple-
`ments a RAT together with the cognitive engine (CE) is
`offered as a service. In this model users are given access to
`radio software on an “on-demand”basis. This eliminates the
`need to install and run the radio software on the radio plat-
`form, which simplifies maintenance and support.
`[0027] The amountof data produced by spectrum monitor-
`ing can be quite large. The amountof data produced is B=Fx
`N,xT bits, where F, is the sampling frequency, N, is number
`of bits per sample, e.g., 32 bits per sample including 16 bits
`per sample of the in-phase (I) component and 16 bits per
`
`11
`
`

`

`US 2016/0037505 Al
`
`Feb. 4, 2016
`
`sample of the quadrature (Q) component, andT is the record-
`ing time. For example, to continuously monitor the band 30
`MHz-6 GHz, assuming a practical sampling frequency of 15
`GHz or 7.5 GHz in quadrature, over 2,500 Terabytes per day
`would be generated by just a single spectrum sensor. Prior
`systems(1) do not monitorthe entire band continuously, and
`(2) reduce the IQ data to only certain time intervals in a
`24-hourperiod, in order generate muchless data, e.g., on the
`order of several GB/hour.
`
`ent types of spectrum sensors can be controlled by cloud 114,
`é.g., using control packets. Context and signal packets from
`the spectrum sensors can be received by cloud 114 and used
`to process data appropriately. A spectrum sensor can be
`deployed without digital electronics except for the packet
`interface. In some examples,all control is performed in cloud
`114. In some examples, the digital subsection of a radio is
`divided between the spectrum sensor 102, 108 and the cloud
`114. In some examples, interpolation, decimation, compres-
`sion, or other processes independentof the specific air inter-
`[0028] The interface to the cloud 114, in some examples,
`face (RAT) in use can be performed in the spectrum sensor
`operates using abstract descriptions of the technical param-
`102, 108 and RAT-specitic processing can be performedin the
`eters ofthe sensors 102, 108. This permits, e.g., replacing one
`cloud 114. In some examples, processing to provide a base-
`or more of the sensors 102, 108 independently of other(s) of
`bandsignal can be performedin the spectrum sensor 102, 108
`the sensors 102, 108. In some examples, packet-based for-
`and at-baseband processing can be performed in the cloud
`mats such as the VITA 49 standard provide abstractions ofRF
`114. In some examples, layered protocol stacks are used, e.g.,
`front-ends. VITA 49 defines two main types of packets: data
`according to the OSI seven-layer modelor other models such
`(e.g., IQ samples) and metadata (data aboutdata, e.g., context
`as the TCP/IP model. Some example stacks include the fol-
`data). VITA 49 packets can be carried over links 116, 118. A
`lowing layers in order: physical (e.g., PHY), data link (e.g.,
`packet format can be independentof the specific technique to
`MAC), network (e.g., IP), and transport (e.g., TCP or UDP).
`carry these packets. The actual interface to the cloud 114 via
`Processing for a selected protocol layer (e.g., MAC) and
`links 116, 118 maybe,e.g., Ethernet or wireless. A metadata
`lower can be performed in the spectrum sensor 102, 108,
`packet can include one or more of the RF center frequency,
`processing for protocol layers above the selected protocol
`bandwidth, sample rate, timestamp, location, or calibration
`layer can be performedin the cloud 114.
`information of one of the sensors 102, 108, and can be gen-
`erated every time one or moreof these parameters changes.
`
`[0033] FIG.1illustrates a cognitive radio cloud. In FIG. 1
`The timestamp can reflect all delays prior to digitization.
`the cloud provider manages the infrastructure that runs the
`Each signal packet stream (also referred to as a “data packet
`radio software. The RF-digital interface can be the interface
`stream”) can be paired with its corresponding metadata
`between the RF FPGA and the cloud 114. The RF-digital
`packet stream using a commonstream identifier. The meta-
`interface can be open and software-based. The cloud 114 in
`data can provide an abstract description of a spectrum sensor
`FIG. 1 can be a distributed antenna system, in which a dis-
`102, 108 and can permit a received RF signal impinging on
`tributed signal processing facility is connected to a remote
`antenna 104, 110 to be, e.g., described exactly or later recon-
`antenna over an analog RF cable. In general, the RF FPGA
`structed. Furthermore, Time Difference of Arrival (TDOA)
`may be connected to the cloud over the Internet.
`localization can be performed using the packet streams from
`[0034]
`In some examples, spectrum sensors 102, 108 are
`multiple sensors 102, 108.
`cognitive radios including cognitive engines (CEs). A CE is
`[0029]
`Since monitoring generates enormous amount of IQ
`an “intelligent” agent that manages the cognition tasks in a
`data, various aspects include compression on the IQ samples.
`cognitive radio. In some examples, the CE learns from the
`In some examples, lossless compression ratios of about 1.5
`current operating environment and from previous events,
`and lossy compression ratios of up to 4 lead to a small
`examinesthe situation, determines and automatically carries
`increase on the bit error rate; furthermore the performance
`out the appropriate response. The CE can be implemented as
`degradation is gradual. Monitoring typically does not involve
`an independententity interacting with the reconfigurable RF
`demodulation of the wireless signals and therefore, compres-
`front-end, or as a collection of interacting entities each ful-
`sion ratios can be much higher. FIG. 5, discussed below,
`filling a specific role. In some examples, the CE can deter-
`illustrates a spectrum sensor 102, 108 that can compress the
`mine whichradio protocol is active at any one time, and at
`IQ samples before transmitting a signal packet (also referred
`whatparameters, such as RF center frequency and RF power
`to as a “data packet’) to the cloud 114. Ifthe sensors 102, 108
`this protocol will operate. Cognitive devices can dynamically
`detect available RATs and available resources.
`perform more computationally intensive steps such as fast
`Fourier transforms (FFTs) or fast feature identification, the
`results can be transmitted as extension packets, also as dis-
`cussed below with reference to FIG. 5.
`
`[0030] Various aspects permit a spectrum sensor 102, 108
`to be controlled by a metadata packet to control its parameters
`such as RF frequency, resolution, or bandwidth. Therefore,
`while the IQ data is transmitted only in one direction, meta-
`data transmission can be in both directions in various
`
`examples, e.g., as discussed below with reference to FIG.7.
`[0031] Various aspects include using VITA 49 as a cloud
`interface. In some examples,
`in a conventional system,
`receipt, downconversion and demodulation are performed in
`the analog system. Thedataare digitized and digital data, plus
`metadata indicating, e.g., the carrier frequency, are transmit-
`ted to the radio.
`
`In some examples, the data are transmitted to cloud
`[0032]
`114 instead of to digital electronics within one radio. Differ-
`
`12
`
`FIG. 2 showsa block diagram of a software-defined
`[0035]
`radio (SDR) system, e.g., embodied in sensor 102. The SDR
`system is connectedto antenna system 202,e.g., antenna 104,
`110, FIG.1.
`[0036] As FIG. 2 shows,the illustrated RF front end is not
`entirely analog; it includes an analog front end (AFE) and a
`digital front end (DFE). In this example, the AFE includes
`amplify/filter/convert block 204 and analog-to-digital/digi-
`tal-to-analog (ADC/DAC)block 206. The DFE 208 can,e.g.,
`perform interpolation or decimation to increase or decrease
`the sampling frequency. Furthermore, the down-conversion
`and up-conversion can be implemented partially or even
`entirely with digital signal processing (DSP).
`In some
`examples, the RF front end or “RFclient” can include antenna
`system 202, amplify/filter/convert block 204, ADC/DAC
`block 206, and DFE 208. Any of antenna system 202,
`amplify/filter/convert block 204, ADC/DAC block 206, or
`
`12
`
`

`

`US 2016/0037505 Al
`
`Feb. 4, 2016
`
`application 222 to a radio, e.g., to make the waveform soft-
`DFE 208 can be connected to digital hardware 210, e.g., via
`an RF-digital interface as described herein. Digital hardware
`ware portable onto different platforms.
`210 can be connected toauser I/O block 212. In the illustrated
`[0042]
`In some examples, an RF-digital
`interface as
`example, software drivers 214 and a real-time kernel 216,
`described herein provides hardware modularity. Some
`e.g., of an operating system, communicate with digital hard-
`example RF-digital interfaces for SDR include a hardware
`ware 210 or user I/O 212.
`bus-type interface. Some example RF-digital
`interfaces
`described herein can operate at various clock speeds and data
`rates. Some example RF-digital interfaces described herein
`transmit metadata, including parameters such as frequency
`and power. Some example RF-digital interfaces described
`herein specify not only receiver interfacing, but also trans-
`mitter interfacing or control of the receiver. Some example
`RF-digital interfaces described herein include a packet-based
`interface that lets the RF subsystem andthe digital subsystem
`be replaced independently of each other. Some example RF-
`digital interfaces described herein describe the RF front end
`and can thus be used as a hardware abstraction language for
`the RF front end.
`
`In an example software-defined radio (SDR), the
`[0037]
`radio access technologies (RATs) at the baseband level are
`implemented entirely in software. A RAT 218(1), 218(N)
`(individually or collectively referred to herein with reference
`218) can implementa radio protocol, or aggregation of pro-
`tocols. For radio protocols implementedentirely in software,
`the digital hardware platform 210 can be programmable.
`Such platforms can be built with general-purpose processors,
`digital signal processors, or field programmable gate arrays
`(FPGAs).
`[0038]
`Software-defined radios can include radios for
`which RFoperating parameters can be modified by software.
`Example operating parameters can include frequency range,
`modulation type, or output power.” An example SDR system
`can implementradio protocols defined after manufacture of
`hardware components ofthe SDRsystem,e.g., using an addi-
`tional or modified RAT 218. SDRarchitecture can include
`
`interconnected hardware and software components, e.g.,
`upgradable software and hardware. Example SDRarchitec-
`tures allow the adding, upgrading, and swapping ofhardware
`and software components. An example SDR architecture
`includes hardware, system software, and service software
`layers, illustrated in FIG.2.
`[0039] The example radio shown in FIG. 2 can operate
`using any one of N different RATs 218, such as Wi-Fi, GSM,
`and LTE-Advanced. The center frequency and powerat the
`RFlevel can be considered completely independent of the
`radio protocol (RAT 218). A cognitive engine (CE) 220 can
`determine which radio protocolis active at any one time, and
`at what parameters (such as center frequency and power)this
`protocol will operate. FIG. 2 can also describe radios that are
`not software-defined (“non-SDR”), in which the radio proto-
`cols (RATs 218) are implemented with dedicated hardware
`that is not programmable. In some examples of such hardware
`radios, each radio protocol (RAT 218) can be connected, e.g.,
`using a closed RF-digital interface, to a separate RF front end.
`[0040]
`InbothSDR andnon-SDR,aradio can support other
`software applications 222(1)-222(N) (individually or collec-
`tively referred to herein with reference 222. Applications 222
`can use services provided by real-time kernel 216. An
`example difference between these software applications 222
`and radio protocols (RATs 218) implemented in software (or
`“radio software,” for short) is that the radio software can have
`muchgreater execution-speed requirements. As a result, the
`radio software can’t be made completely independentof the
`digital hardware 210, which is indicated by the dotted lines in
`FIG.2. This is the main barrier to implementing radio proto-
`cols 218 entirely in software. In some examples, the RF-
`digital interface is closed, the radio protocols (RATs 218) can
`be hardware dependent.
`[0041] Various examples of open architectures use defined
`interfaces. For example,
`the Software Communications
`Architecture (SCA) defines a set of interfaces that isolate the
`radio applications from the hardware. In another example,
`APIs (application program interfaces) defined in C++, VHDL
`(VHSIC Hardware Description Language), and IDL (Inter-
`face Definition Language) can permit interfacing a waveform
`
`In various example, digital hardware 210 or other
`[0043]
`components of the radio include one or more reprogram-
`mable RF FPGA(s) that include one or more components
`such as low-noise amplifiers, power amplifiers, mixers, fil-
`ters, or matching networks. In various examples, the compo-
`nents, the topology, or both are software-defined. In some
`examples, an RF FPGA can include data convertersor digital
`signal processing that is independentofthe radio access tech-
`nology (RAT 218). Examples of such processing can include
`decimation or interpolation. In some examples, such an RF
`FPGA can beorbe part of a “thin radio client.” A thin radio
`client can include, e.g., an RF front end and a packet-based
`RF-digital interface. A “fat radio client” can include, e.g.,
`both analog resources such as those found in a thin radio
`client and processing resources to perform basebandprocess-
`ing of received signals or signals to be transmitted.
`[0044] RF FPGAsin some examples can implement RATs
`218 to be defined after manufacture ofthe RF FPGA. Accord-
`
`ing to someprior schemes, RF ICsare optimized for a single
`RATandare re-designed for every new RAT. Moreover, RF
`ICs according to some prior schemes are connected with a
`closed interface to the digital hardware for which they are
`designed. RF FPGAsas described herein can be RAT-inde-
`pendent, so can use an open (non-RAT-specific) interface.
`Various examples herein of an open interface and a HDL for
`RF FPGAsinclude packet communications.
`[0045]
`FIG. 3 shows an example RF-digital interface and
`related components of a radio 300. In this example, digital
`hardware 210 includes encoder 302 having control packet
`encoder 304 and signal packet encoder 306. Packets from
`encoder 302 are transmitted across the RF/digital interface to
`RF-side parser 308 including signal packet decoder 310 and
`control packet decoder 312. Signal packets from signal
`packet decoder 310 include data to be transmitted. These data
`pass through digital front end (DFE) 314 anddigital-to-ana-
`log converter (DAC) 316. Analog data from DAC 316 passes
`through upconverter/amplifier/filter (UAF) block 318 and
`duplexer 320 to antenna system 104. Software control mod-
`ules 322, 324, and 326 control the operation of DFE 314,
`DAC 316, and UAF 318, respectively, in response to signals
`from control packet decoder 312. Software control module
`328 controls the operation of duplexer 320 and antenna sys-
`tem 104 in response to signals from control packet decoder
`312. In some examples, Global Positioning System (GPS)
`receiver 330 or another location sensor provides information
`of a location of radio 300.
`
`13
`
`13
`
`

`

`US 2016/0037505 Al
`
`Feb. 4, 2016
`
`[0051] Controlli