California Institute forEnergy and Environment

California Institute forEnergy and Environment

E n e r g y R e s e a r c h a n d De v e l o p m e n t Di v i s i o n F I N A L P R O J E C T R E P O R T

ENABLING TECHNOLOGIES DEVELOPMENT GRANT PROGRAM Final Report 2002-2015 Appendix J

JUNE 2015 CEC-500 -2016-011-APJ

Prepared for: California Energy Commission Prepared by: California Institute for Energy and Environment University of California

APPENDIX J Appendix J: Appendix 4: Network Agility and Management for Demand Response/Sensor Networks

2087 Addison Street, 2nd Floor Berkeley, CA 94704-110

(510) 643-1440 uc-ciee.org

California Institute forEnergy and Environment

Network Agility and Management for Demand Response/Sensor Networks

Final Project Report September, 2007 Prepared by CyberKnowledge and University of California, Berkeley Prepared for CIEE Enabling Technologies Development Program Program Manager Gaymond Yee

1.0 INTRODUCTION

1.1. Introduction: Future Proofing Demand Response Infrastructure

Demand Response (DR) is a set of mechanisms that provides electricity customers in both

retail and wholesale electricity markets with a choice whereby they can respond to dynamic

or time-based prices or other types of incentives by reducing and/or shifting usage,

particularly during peak periods, such that these demand modifications can address issues

such as pricing, reliability, emergency response, and infrastructure planning, operation,

and deferral. There is growing consensus at both the state and national levels of the

importance of Demand Responsiveness and the complementary role of energy efficiency in

achieving California and national energy policy imperatives.

Ongoing Demand Response Enabling Technology Development (DRETD) [Yee 2003]

research efforts are targeting New Thermostat and New Meter devices, equipped with

sensors and nominal communication capabilities, and designed for use in residential homes

[Arens-Wright]. Concomitantly, several of the Investor Owned Utilities (IOUs) in California

are at various stages in the deployment of the next generation of Advanced Metering

Infrastructure (AMI).

In order for the Utilities (IOUs) and the California Independent System Operators (CAISOs)

to deploy, provision and manage such devices, it is necessary to have an appropriate

service, network management and communication infrastructure that enables

communication with these meters and sensor nodes in the field in a scalable and reliable

fashion. There is often a large sunk investment in legacy communications/networking

infrastructure and back-end systems that support them. It is therefore very attractive for the

utilities and ISOs to seek an architecture that allows them to maximize their return on

investment. Ideally, for maximum cost-effectiveness, a network vision should

accommodate existing (legacy) infrastructure, while harvesting the benefits of evolving

communications technologies in three dimensions:

� Evolution in home networks and in-building networks that target

communication inside the home or enterprise;

� Evolution in wired/wireless access networks, in the form of medium-range

mesh networks, local area networks, and metropolitan area networks; and

� Evolution in wired/wireless backhaul networks and wide area networks.

16

1.2. Project Objectives

The long-term goal of the research described here is to provide a basis for future-proofing

the Demand Response network, minimize stranded assets, and preserve investment in

software platforms, while enabling deployment of newer low cost hardware platforms in

an incremental fashion. More specifically, this research is aimed at exploring emerging

technologies in the domain of agile radios, with a view to leveraging these advances, as

well as ongoing potentially disruptive changes in spectrum regulatory policy, in the context

of the Demand-Response network architecture.

In order to progress towards these long term objectives, it is important to understand the

requirements of applications and systems in the Demand Response context, the overall

capabilities of emerging technologies and their projected timeline, and develop an

architecture that meets these capabilities.

1.3. Section Outline

This section provides a brief background for the current research effort, related to Network

Agility and Management. A brief background related to DR (Demand Response) and AMI

(Advanced Metering Infrastructure) is provided in Section 1.2. The project objectives are

described in Section 1.2. Background related to Sensor networks is provided in Section 1.4.

The problem that is addressed by this research is described in Section 1.5. Some of the

benefits of having Agile Nodes are summarized in Section 1.6. Section 1.7 summarizes the

overall organization of the remainder of this report.

1.4. Background: Sensor Network Architecture: Subsystems and Networks

Figure 2 depicts at a high level some of the subsystems and networks comprising the

Demand-Response Network Architecture that we will use as a basis for our discussion.

These are briefly described below.

� Sensors, Sensor Clusters and Sensor Networks.

To begin with, there is a collection of sensors and actuators at the user premises,

also referred to as the “Home/Enterprise Building” level. Examples include

temperature sensors, and a thermostat/control system that regulates the airflow in

heating/cooling ducts via registers and that controls various appliances such air

conditioners and water heaters.

Depending on the size of the installation, the number and types of sensors

deployed, their geographic distribution, and other relevant factors, it can be useful

to group together some of these sensors/actuators to form a number of sensor clusters

(and perhaps even a hierarchy of sensor clusters).

17

� Cluster gateway node(s)

Each sensor cluster can have a cluster gateway node that acts as the proxy for that

cluster. Analogously, the entire sensor network at the building level can have a

network gateway node. In a residential context, a “neighborhood gateway node”

may serve a group of homes in a neighborhood.

� Building gateway node(s)

The Home/building control subsystem may be comprised of one or more building

gateway nodes, sensors for different attributes (such as temperature, light,

humidity, etc), and enterprise monitoring & control subsystems. Further, the

building network gateway node will typically have scaleable LAN/WAN

connectivity, usually via an appropriate access network, either wireless or wired.

Examples of typical access networks include

o Wired networks such as DSL, Cable, Leased line, Passive Optical Networks

(PONs)

o Wireless networks, such as 2/2.5/3/nG, …, and 802.11x networks, as well as

Mesh networks in the licensed and unlicensed bands.

� Backhaul Networks

The access networks provide connectivity to backhaul networks. Examples of

Backhaul networks include:

o Private Enterprise Networks, e.g., leased lines/Wide Area Networks.

o Public Internet

� Other Networks

Eventually, the backhaul networks provide a link to the enterprise networks owned

and operated by customers of the DR Network, such as Investor Owned Utilities

(IOUs) e.g., PG&E, Power generators and Independent System Operators (ISOs).

These customers need to be able to deploy, provision, manage, and control the

network services, broadcast or multicast pricing information, load characteristics,

etc., and (selectively) obtain data from various end users for local processing on

enterprise back end systems.

18

Figure 1 Fragment of an Example AMI deployment for a utility (Courtesy SCE)

35

Demand-Response Network Architecture: Representative Subsystems & SubnetworksDemand-Response Network Architecture: Representative Subsystems & Subnetworks� Building level (“User premises”)

� Scalable Sensor clusters/ Sensor network

� Cluster gateway node(s)

� Building control subsystem with communication

� Building gateway node(s)– Home meter

– Enterprise monitoring & control system

� Scalable LAN/WAN connectivity in the building gateway node

� Access networks

� Wireless e.g., Mesh networks (Licensed/unlicensed bands), 2/2.5/3/nG, …

� Wired e.g., DSL, Cable, Leased line, PON, …

� Backhaul

� Private Enterprise Networks, e.g., leased lines/WANs, QoS

� Public Internet

� Other networks

� Enterprise networks

� SCADA networks

ClusterGateway

Node

SensorNodes

Sensor

Cluster

Network

Gateway

WAN

Client Data

Browsing/

Management/

Processing

Data Service

SCADA

Figure 2. Examples of Subsystems & Networks in a Sensor-Network Based DR Architecture

1.5. Problem Addressed. Relevance in the Demand-Response (DR) context

When Demand-Response (DR)/sensor networks are deployed in the field, they will employ

multiple sensors (e.g., temperature and light sensors), multiple devices (e.g., control

19

thermostats, home meters), and multiple wired and wireless networks with various Air

Interface Standards (AISs)c (AIS’s are synonymous with wireless protocols). Further, the

number and nature of consumer/wireless electronics devices and associated wireless

infrastructure and standards continues to evolve at a rapid pace. It is necessary to have the

ability to design, deploy, provision, and manage these networks, services and devices on an

ongoing basis. The complexity of these tasks is vastly increased because of the need to

accommodate multiple, differing radio/air interface standards; the need to manage a

multiplicity of devices, many with configurable software, radios, and firmware; and the

need to accommodate different service deployment contexts (e.g., variations in the number

and nature of sensors and control/communication devices, different types and levels of

services provisioned, etc.).

This research relates to following enabling technologies in this context:

� Technologies that enable a (flexible) gateway node to serve as a bridge between the

growing variety of sensors on one hand, and the still expanding array of Wide Area

Networks (WANs) and Metropolitan Area Networks (MANs) on the other hand;

and in particular, technologies that enable Network/Spectrum (RF)/AIS Agility.d

� Technologies that support key aspects of Network Service Deployment &

Management. Some of the functionality we investigate in this context relates to

enhanced life-cycle management for devices, and the ability to remotely provision

devices.

1.6. Benefits of agile nodes in the context of DR networks: The 10x10 Target

It is useful to frame the potential benefits that may be gained from the development and

eventual deployment of the technology explored in this proposal in the context of the ten-

fold improvement in functionality and cost targeted by Demand Response Enabling

Technology projects.

Demand-Response Networks accrue several direct benefits from employing agile

communication nodes, including

c An Air Interface Standard or AIS is a term used to refer to a standard wireless protocol used for communicating

over a radio interface. Examples of Air Interface Standards in the unlicensed frequency bands include the IEEE

802.11b standard for wireless LANs operating in the 2.4GHz band, the IEEE 802.15.4 standard for low power

low data rate communications operating in the 2.4 GHz band, and the IEEE 802.11a standard for wireless LANs

in the 5 GHz band. Examples of AISs in the licensed frequency bands include the standards for cellular

technologies such as GSM, CDMA, WCDMA, CDMA2000, etc.

d AIS agility refers to agility with respect to Air Interface Standards (AISs), i.e., the ability to adapt to various

wireless protocols, and in particular, be able to communicate using more than one wireless protocol.

20

� The ability to support configurable, software-defined radio nodes. This makes it

possible to ride the (reducing) cost curve in hardware deployments in new

buildings and homes, while enabling software service deployment platforms to be

reused. Additionally, this enables

o Software download of new, enhanced (1) radio functionality; (2) service

functionality;

o Policy defined management and operation of DR networks.

� The ability to leverage evolving new technology in agile radios.

� The ability to have access to a diversity of wireless channels, and use the best

available wireless/network channel.

� Improved redundancy at the system and network level, by virtue of having access

to more than one transit network for communication. These options can be used to

transmit and receive data, as well as to transmit and receive control signals.

� The ability to deploy and manage new services across such networks.

� The ability to adapt the network dynamically to reflect business processes and

network policy.

� The ability to leverage new spectrum policy that is projected to evolve significantly

over the next several years.

� The ability to obtain the best possible network rates.

Thus, the use of agile, software-defined radio nodes can provide a superior ability to

manage, upgrade and provision new services. The advantages of establishing an open,

modular, common service deployment platform include: broad acceptance of the

technology, and potential standardisation, resulting in lower development and acquisition

costs. In addition, this technology can help reduce stranded assets by supporting legacy

radio/sensor interfaces, while “future-proofing” deployments (within pragmatic limits) and

reducing operational costs by enabling software download of new radio functionality, and

enhanced services. As a consequence, the capabilities enabled by the proposed research

and the cost efficiencies obtained will meet the 10x10 functionality and cost improvements

goals of the DRETD project.

21

Relevance to Demand-Response Research Opportunity Notice

As a point of reference, this proposal spans the following DR Enabling technologies listed

in the Network Management Research Opportunity Notice [Yee 2003].

� Channel Agility

o Technologies that can dynamically determine the best communications

medium, and adapt to the RF frequency (spectrum) of that medium.

� Adaptive Protocols

o Technologies that can dynamically determine the best communications

medium, and adapt to the protocols of that medium.

� Network Operation/Management

o Technologies to permit management of the network in a distributed manner.

1.7. Report Organization

The remainder of this report is structured as follows. Section 2 describes the project

research related to the investigation of stakeholder perspectives and use case scenarios,

leading to the articulation of system requirements. Section 3 summarizes the project

research related to Agile Radio Nodes. Section 4 delineates how agile networks can

interface to Utilities and Service Providers on the one side, and to sensor networks on the

other side. Section 5 reviews the benefits for California as a result of this research and its

follow on. Finally, a glossary and a set of appendices include a summary of background

information intended to improve the readability of this document.

22

2.0 PROJECT OUTCOME: STAKEHOLDER PERSPECTIVES & SYSTEM

REQUIREMENTS

2.1. Introduction

This section examines representative scenarios that arise in different contexts related to

Demand Response systems, and that can arguably benefit from agile functionality. These

scenarios are then amalgamated to identify a useful set of features in a system that supports

network agility.

The goal of the work related to use case scenarios is

� To identify the representative stakeholders in the DR ecosystem, and to articulate

the perspectives of various participants or “actors” in the Demand Response

context, and

� To use these perspectives as a basis for defining the system level requirements and

technology capabilities that are needed in order to enable the envisioned use cases.

More specifically, our objective in this research is to identify the desired functionality

related to network agility and sensor/device management that benefits these use cases from

a DR perspective.

2.1.1. Section Outline

Section 2.2 provides a brief background relating to use cases in systems engineering.

Section 2.3 identifies representative stakeholders in the DR business ecosystem and

summarizes the perspectives of these stakeholders. Section 2.4 elaborates on the role and

usefulness of Agile systems in the context of DR/AMI.

2.2. Use Cases: Role in Systems Engineering

In software engineering and system engineering, use cases provide a technique for

capturing functional requirements of systems and systems-of-systems. Each use case

provides one or more scenarios that convey how the system should interact with the end

users or other systems to achieve a specific business goal or function.

The overall goal of developing use case scenarios is to assemble a set of desired system

attributes that need to be considered in developing a specification of system requirements,

capabilities of subsystem components, and a detailed system architecture.

Use cases focus on what the desired behavior should be, rather than how this behavior is

achieved; the latter, i.e., a description of how a desired function may be achieved, is a

23

function of the system architecture, and requires a more detailed elaboration, analysis and

implementation process. The architectural elaboration entails trade-offs between various

dimensions/attributes of the design such as function, performance, cost, robustness,

power/energy consumed, etc. An overlay of this information with the evolution of

technology and the prioritized attributes of the system requirements can suggest a useful

architectural roadmap.

2.3. Representative Stakeholders and Perspective in the DR Ecosystem

Representative stakeholders relevant in the Demand Response context include the

following (Figure 3):

� Utilities/Service providers (such as PG&E, SCE, SDG&E, etc.) and CAISO

(California Independent System Operators)

� Communication Network Operators (providers of WANs, MANs, wired and

wireless networks)

� (Communication) Spectrum Regulators (e.g., FCC, NTIA)

� Energy Regulators (such as the CEC, CPUC)

� Home networking (Consumers)

� Equipment providers (such as thermostat manufacturers like Honeywell, GE, etc.)

� Component suppliers (third party hardware and software providers)

Demand-Response

(/AMI)

Consumer

(Residential,

Commercial)

Service Provider

{Utility, 3rd party}

Network Operator

{Utility, 3rd Party}

Equipment Vendor

{e.g., Thermostats,

Meters, …}

Component Vendor

{SW/HW

components}

Regulators

Energy: CEC, CPUC, …

Spectrum: FCC, NTIA, …

Network

Equipment

Vendors

System

Requirements

24

Figure 3 Use Case Scenarios: Actors/Perspectives in the Demand Response Context

We have developed and/or investigated use case scenarios that are relevant from the

perspectives of some of these stakeholders. This section summarizes our research on these

perspectives.

The overall objective of our research task was to articulate and then aggregate the

requirements drawn from these perspectives. During a subsequent architectural analysis,

we will categorize these requirements in terms of the implementation trade-offs and cost-

performance benefits. Such requirements may be categorized based on their perceived

degree of “criticality” to stakeholders: must-have, nice-to-have, not needed. The envisioned

result is a set of functions that the system can support, and that is of interest to the

stakeholders.

2.3.1. Demand-Response (DR) Deployment Scenarios

Demand Response (DR) entails transmitting emergency signals (such as critical

peak pricing and mandatory curtailment signals) and price signals to the user, with the

expectation that the consumer will respond appropriately. It is planned that such signals

will be transmitted in real-time or near real-time. The intent is to enable the

utility/California ISO to communicate emergency and pricing signals to the user; the return

channel from the user to the utility can be used for confirmation and/or transmitting other

information of relevance, e.g., power usage data. As a consequence, in the Demand-

Response context, there is a need to have at least a 1-way (and preferably a 2-way)

communication between the utility and a control point at the customer premise/residence.

This control point/system will likely be a component in a distributed,

programmable control thermostat. At the time of the writing of this report, various

California utilities (IOUs) such as PG&E, SCE, SDG&E are contemplating potentially

disparate sets of technologies that might be rolled out in the context of an AMI

deployment.e This scenario suggests the need to have a somewhat harmonized operational

perspective from the standpoint of California ISOs. Even within the announced plans for

each specific utility, there is the possibility of multiple technologies being deployed.

e Private communication, from Ron Hofmann, Gaymond Yee, and other IOU stakeholders.

25

Utility Owned

Consumer Owned

Private Fixed NetworksWAN/LAN

Anyintervalmeter

orpole-topcollector

PSTN/DSL/Cable/SatelliteWAN/LAN

2-way2-way

Any gateway (protocol xfr)

•Special box•Internet modem•Router

•Media PC•Security panel

• ……..

HAN Protocols³ZigbeeZ-wave

InsteonWi-Fi

EIA709HomePlugBluetooth

2-wayT24 PCT

RDS/FM or pager broadcast

1-way

2-way

HAN access using expansion port

Sub-meter

Appliances

Display Devices

1.e.g., 802.11b, proven mesh LAN protocol, etc.

2.To be determined

3.Up to 45 active protocols worldwide

Broadband TV, music

2-way

2-way

2-way

• interval energy• time

• billing start time• peak power• messages• acknowledgements

• price signals• reliability signals

RF-TX1

PLC-TX²

and/or

Third-Party Provider

Third-Party Provider

Third-Party Provider

Third-Party Provider

2-way

2-way

Figure 4 A Plausible deployment scenario for DR/AMI including a Gateway and PCT

(Programmable Communicating Thermostat) (Courtesy Ron Hofmann)

For example, in the case of SCE, the current vision calls for an AMI infrastructure

that will use ZigBee to communicate between the AMI Home Energy Meter (owned by

SCE) and the home network (potentially including some form of programmable control

thermostat). However, there is the realization that multiple technologies may very likely be

used within the home, and there is a need to extract the appropriate information from the

different devices that are relevant to SCE, and communicate this to the SCE AMI meter

using Zigbee. At this stage, SCE has not decided on the communication infrastructure that

will be used to connect AMI to the SCE backend, except to acknowledge that this will

require a substantial investment. PG&E is in the process of deploying AMI in its territory,

and is exploring various options for interfacing to the home network and evolving PCT

technology. Also, to the best of our knowledge, SDG&E’s strategy is somewhat similar to

that of SCE.

The perspectives discussed above suggest that there is a need for:

� Network and communication agility at many different levels; for example, at the

home gateway level and at the neighborhood gateway level. Agility in the home

gateway can allow for adaptation to specific home devices and communications

mechanisms in the home, and for the evolution of wireless protocols over time.

26

Agility in the neighborhood gateway node can additionally enable adaptation to

various alternative backhaul channels; such agility has benefits because of

increased reliability due to additional backhaul channels, and because the

lowest cost channel can be chosen at any point in time. In addition, there is

benefit to having agile architectures in the infrastructure, for example in the

wireless basestations; indeed, wireless carriers are already in the process of

assessing and deploying such capability. Furthermore, even terminal devices

can benefit from agility in that many emerging portable devices need to support

multiple protocols, for example, WiFi, Bluetooth, Cellular (GSM, CDMA,

UMTS), Mobile TV, WiMAX, and UWB.

� A distributed, open architecture to support the different paradigms that are

likely to be adopted by the various stakeholders.

Questions that need to be addressed in this context include, for example:

� Will the DR communication infrastructure use an existing mechanism, such as a

narrowband/broadband connection into the house; or will a “new” mechanism

be employed in the context of the Energy grid? Plausible examples that have

been considered include a paging network/system, and data embedded in FM

channels (RDS) that has been experimented with in the context of PCTs

(Programmable Communicating Thermostats).

� If so, how will this communication layer interface to the AMI/utilities?

� How will the CEC/CAISO/CPUC deal with the multiple networks and

mechanisms? What should be legislated and/or standardized? And conversely,

what should be left unspecified so as to encourage innovation and competition

in the industry?

2.3.2. Utilities and (Energy) Service Providers

From the perspective of service providers, the following capabilities are important.

� Capabilities for provisioning new services.

� Capabilities for remotely monitoring, managing and controlling components of

the network, including devices at home and the home meter.

� Capabilities for upgrading software in the network. Such software can be used

for upgrading device capabilities, customer services, as well as for “patching”

(repair) of bugs in equipment that has already been deployed in the field.

27

If an agile software platform capability is available, then the associated set of capabilities

for upgrading/modifying software/radio characteristics, intelligently leveraging and

trading-off different channels of communication, etc. are important. Further, additional

service-specific capabilities defined by the service providers are also relevant.

2.3.3. Regulatory Perspective

There are two disparate sets of regulatory agencies whose charter and perspectives are

relevant in the context of network agility in DR networks.

� Energy regulatory agencies, such as the California Energy Commission (CEC) and

the California Public Utilities Commission (CPUC) are concerned with Energy

efficiency and Demand/Response capabilities, for instance, and need to be able

mandate/legislate appropriate policies and standards, and then oversee the roll out

of these mandates and all subsequent enforcement as appropriate.

o It is arguably beneficial to develop a vision, reference designs and proofs of

concept in order to first provide an initial demonstration of functionality that

is achievable and cost points that may be feasible, and second, to provide a

platform that can be used as a basis for further development by industry.

o The attendant technical needs relate to supporting Demand-Response

capabilities mentioned earlier, and also for supporting monitoring and

enforcements of aspects of security and privacy.

� Communication regulatory agencies, such as the Federal Communications

Commission (FCC) and National Telecommunication and Information Associationf

(NTIA) are chartered with regulating the wireless communication spectrum in use

within the USA. (Analogous agencies exist in other countries worldwide.)

o The FCC is interested in being able to specify and mandate/legislate

spectrum policies in various public, commercial and military domains.

Agile/cognitive radio architectures need to be both responsive to such

policies and respectful of primary users in any part of the spectrum.

o One of the main requirements for regulatory agencies such as the FCC is the

specification and certification of the radios. Having radio characteristics

modifiable in the field is an arena that is very nascent, and the modalities of

f NTIA is the President's principal adviser on telecommunications and information policy.

28

certification need to be fully understood, and mechanisms to support the

agency charters need to be developed.

2.3.4. Consumer perspective

There continues to be an explosion in the number of consumer devices at home and the

enterprise, and a concomitant evolution in standards. From a consumer’s perspective, the

high level system requirements are related to ease of use, interoperability, the ability to

seamlessly switch between various networks (personal area networks, local area networks,

wide area networks, metropolitan area networks, and alternative networks), provide the

least cost anytime anywhere service, provide the required quality of service where needed

(e.g., in media and control interactions), and support the desired levels of privacy and

security at affordable price points. A number of these requirements can leverage agile radio

platforms, particularly when they meet the required cost points and power points. In the

interim, they can more immediately be used in infrastructure components, such as base

stations and home gateways.

2.3.5. Equipment Providers/Vendor Perspective

Vendors here nominally include end equipment vendors, as well as hardware and software

component suppliers for these vendors. From the perspective of a vendor, it is important to

be able to address the system level requirements, while having a reusable set of

components that can be leveraged in different markets. Typically, different markets are

characterized by variances in standards, and consequently the ability to adapt a common

set of building blocks to the varying set of local requirements is crucial for business

sustainability.

2.4. The Role of Agile Systems in the Demand-Response/AMI context

To make some of the preceding discussion more concrete, we delineate in this section a

basic scenario that has representative components of a Demand-Response infrastructure. In

the context of such a scenario, we illustrate different ways in which an agile radio platform

can be used.

Figure 5 depicts a residence (synonymously, customer premise) that includes home

gateway node, an energy meter normally located on the outside of the house/building that

is owned and controlled by the Utility/Energy service provider, and a thermostat within the

house (typically owned by the homeowner) that nominally controls existing heating and

cooling systems.

The vision for the Advanced Metering Infrastructure deployments being considered is that

the older generation of energy meters will be replaced by new next-generation energy

29

Meters. It is envisioned that these new energy meters will be connected to the utility and

controlled by them, and provide benefits in various dimensions, including support for

automated meter reading, operations, maintenance and diagnostics, real-time or near real-

time meter reading, etc.

Next generation thermostats, envisioned to eventually replace existing thermostats, are

designed to accept inputs from sensors (such as temperature, humidity, lighting levels,

etc.), and have actuator outputs that control various household appliances such as HVAC

systems and pool pumps. Such devices are currently evolving in the research domain, and

are likely to be mature and be deployed in various forms over the next few years.

A short-to-intermediate term approach to enabling Demand Response for consumers that is

currently being considered entails the introduction of a “Programmable

Communicating/Control Thermostat” (PCT) that is designed to replace a conventional

thermostat. The PCT is designed to have a communication channel with the Utility/ISO.

This communication channel can be designed to be one-way (from the utility or CAISO to

the PCT) or two-way (i.e., consisting of a bi-directional channel between the utility/CAISO

to the PCT). DR related signals, such as pricing signals, as well as DR-emergency signals,

are communicated by the utility/CAISO to the PCT at the customer premises. The PCT is

then designed to take the appropriate action, e.g., monitor and/or control (via actuators)

HVAC equipment. In principle, the communication and control can potentially span a

much broader set of home appliances.

Given such a context, some of the utility plans and roadmaps project a communication link

between the meter and a gateway in the home network. In particular, the SCE (Southern

California Edison) plan requires a Zigbee link between the meter and a point within the

home. (Our understanding is that it is not mandated that this Zigbee link exist between the

gateway and all other devices, merely that the gateway should be able to talk to the AMI

meter.)

30

Utility/Service Provider

Internet

EnergyMeter

Sensors

HouseholdAppliances

HomeNetwork Gateway

Node

Gateway

Node

Thermostat

(PCT)

Advanced Metering/Demand-Response (DR) Context

Figure 5. Advanced Metering Infrastructure and Demand Response Context

A typical residential gateway (or home gateway) is a hardware device that connects a home

network with a wide area network (WAN) or the Internet. The residential gateway

provides port translation, allowing all the computers in a small home network to share one

IP address and Internet connection. The residential gateway may sit between the modem

that interfaces to the external wide area network and the internal network; alternatively, a

modem may be integrated into the residential gateway. A residential gateway often

combines the functions of an IP router, multi-port Ethernet switch and WiFi access point.

Residential gateways that include routing capabilities are converged devices and

sometimes referred to as home routers or broadband routers with "broadband" in this case

referring not to the router function but the Internet access function.

Our focus here is on the capabilities of a home gateway node that has (or interfaces to) a

modem which connects to a wireless wide area and/or home area networks. Current

examples of wireless wide area networks supported include “broadband” wireless access

networks supporting either WiFi access or WiMAX protocols; they also include cellular

wide area networks, such as those provided by commercial cellular operators, e.g., GSM,

CDMA, WCDMA. (Niche applications interface to lower bandwidth paging networks or

other proprietary networks.) Traditionally, such a gateway node is designed to support a

single wide area access protocol on both the wide area and home network side (or

occasionally, a small number of preselected and hardwired frequencies and protocols). We

31

refer to such a traditional gateway node as a non-agile wireless gateway, and suggest that

that the addition of agile functionality to such a node can be extremely valuable in the DR

context.

2.4.1. Communication Mechanisms using traditional (non-agile) Wireless

gateway

Figure 6 illustrates some of the communication mechanism(s) that would need to be

supported within a home by a conventional (non-agile) wireless gateway if it were

designed to communicate with representative sensors and other devices that have evolved

just over the past few years.

� A microclimate multi-sensor node (MEP410CA) that was introduced by Crossbow

(www.xbow.com) used a 433 MHz Radio, and a proprietary protocol. If this sensor

node were deployed in the house, the control gateway would need to have a radio

that implemented this proprietary protocol, using a radio in the 433 MHz band.

� Several manufacturers, such as Toshiba, have introduced, over the last few years,

appliances such as Washer-dryers, Air conditioners, and microwave ovens, which

include support for Bluetooth technology. In order to communicate with and

control such devices remotely, the Bluetooth standard would have to be supported

by the gateway. It is also relevant to note that Bluetooth standards themselves have

undergone several evolutions since they were introduced, and have gone through at

least three major changes. (The most recent of these involves the adoption of the Ultra

wide band technology as then next generation radio standard for Bluetooth

devices.)

� The third example shows a recent “MICA” mote that uses the ISM 2.4 GHz band, an

IEEE 802.15.4 radio, optionally running the Zigbee stack. In order to communicate

with this device, the gateway would need to support the IEEE 02.15.4 standard and

the Zigbee layer.

These examples highlight the fact that several “attractive” wireless technologies and

protocols have evolved, just over the last five years (during 2000-2005). If a conventional

non-agile gateway were to be used, it would be restricted to communicating over only one

of these protocols. More sophisticated non-agile gateways would at most be capable of

communicating with a small, fixed subset of such protocols. Furthermore, neither of these

classes of gateways would be capable of being upgraded after deployment, thus rendering

them of limited value once newer devices were added to the home.

32

EnergyMeter

Sensors

HouseholdAppliances

HomeNetwork

?

DR

Gateway

?

DR

Node

•433 MHz Radio

•Proprietary Protocol

433 MHz

Proprietary

Radio Protocol

?

DR

Node

•2.4GHz ISM band

•IEEE 802.15.4/

ZigBee™ radio

2.4 GHz

IEEE 802.15.4 PHY

Zigbee Stack

TOSHIBA

Bluetooth Enabled

Dryer,

A/C, Microwave, …

?

DR

Node

2.4 GHz

Bluetooth Radio

& Protocol Stack

Others standards: e.g.,

2.4 GHz/5.x GHz

IEEE 802.11 a/b/g/I/n/…, Z-wave, …

Traditional (Non-Agile) DR Gateway Node: Communication within the Home.

Several (Incompatible) Deployment Alternatives just during (2000-05) would have resulted in “Stranded”

devices/HW/SW/…, meters, infrastructure, …

Figure 6. Communication within the home using non-agile gateway nodes:

Multiple protocols require multiple nodes, and flexibility after deployment is lost.

2.4.2. Residential Communication Mechanisms using Agile Wireless gateways

Figure 7 illustrates how a single agile gateway node can be used to communicate with the

array of disparate devices alluded to above, using an assortment of air interface standards

(in Figure 6). Such an agile gateway node would have to be provisioned with the ability to

communicate using the protocols of interest, namely the proprietary 433 MHz protocol for

the MEP410CA, Bluetooth, and Zigbee. It would also need to have a radio that is capable of

operating in the 433 MHz band, and the 2.4 GHz band.

The important point to note is that these capabilities can be provisioned after the initial

deployment of the gateway device, with the assumption that agile device is equipped with

adequately configurable radio capabilities, and is capable of being programmed remotely.

The significance of the ability to provision new radio capabilities and modify functionality

after deployment is that it mitigates the need for physical “truck-rolls” that are traditionally

required for this purpose. It also enables software upgrades to be provided when needed,

without requiring a physical visit to the customer premises, or by the customer to the utility

offices. Another measure of the importance of such a capability is the observation that

business plans in the communication and cable industry are often rendered unviable if

multiple visits are required to customer premises after initial installation. The elaboration

of such capabilities and scenarios, along with investigation of enabling technologies is the

task addressed by this project.

33

EnergyMeter

Sensors

HouseholdAppliances

HomeNetwork

?

DR

Gateway

•433 MHz Radio

•Proprietary Protocol

433 MH

z

Proprie

tary

Radio P

rotocol

•2.4GHz ISM band

•IEEE 802.15.4/

ZigBee™ radio

2.4 GHz

IEEE 802.15.4 PHY

Zigbee Stack

TOSHIBA

Bluetooth Enabled

Dryer,

A/C, Microwave, …

Agile

DR

Node

2.4 GHz

Bluetooth Radio

& Protocol Stack

Others, e.g., 2.4 GHz/5.x GHz

IEEE 802.11 a/b/g/I/n/…

Multiple Protocols can be remotely provisioned/downloaded

� Dramatic reduction in “Stranded” devices/HW/SW/infrastructure, …

Agile DR Gateway Node: Communication within the Home

Figure 7 Communication within the Home using Agile DR Gateway Nodes:

A single agile node, appropriately provisioned, can communicate over multiple protocols

2.4.3. External Communications: Leveraging Radio/Network Agility

This figure illustrates the relevance and usefulness of radio and network agility in the

context of communications external to the home.

EnergyMeter

Sensors

HouseholdAppliances

HomeNetwork

?

DR

Gateway

?

DR

Node

•2.4 GHz Radio

•IEEE 802.11b

2.4 GHz

IEEE 802.11b

?

DR

Node

2.5/… GHz

IEEE 802.15.4 PHY

Zigbee Stack

?

DR

Node

PCs

Mobile

cellular or satellite link

•2.5/3.5/5.8

GHz Radio

•IEEE 802.16

•WiMAX

800-900 MHz

1.8-1.9 GHz

2G, 3G,

CDMA, WCDMA,

UMTS,

IEEE 802.11 a/b/g/I/n/…

(Non-Agile) DR Gateway Node: External Communications WAN/LAN/MAN

Several (incompatible) Deployment Alternatives (2000-05)

���� Stranded HW/SW, meters, infrastructure, …

34

Figure 8. Applications of Agile Platform for communications external to the home

Several wide area and metropolitan area technologies have evolved over the last few years.

Examples include:

� Prevalent and evolving standards used for cell phones, in various bands spanning

800, 900, 1800-1900 MHz, such as GSM, CDMA2000, UMTS, and WCDMA to name

just a few.

� Metropolitan and local area networks based on various incarnations of 802.11

b/g/n/… technology in the ISM 2.4 GHz and 5 GHz bands.

� And more recently, WiMax technology in the 2.5 GHz, 3.6 GHz, and 5.8 GHz bands

is being promoted as an attractive alternative for deploying wireless wideband

services.

A conventional gateway design for a home/customer premises device would need to select

one technology for external communication, such as WiMax or 802.11g. It would then be

incapable of using other potential alternatives that might be evolved and potentially

provide better performance or lower cost.

As illustrated earlier in the case of communication needs within the home, having an agile

radio platform that supports network agility can alleviate the pain (financial and functional

costs) caused by this category of problems.

2.4.4. Summary: Agility is very relevant in the DR/AMI context

The scenarios considered above suggest that there is a significant advantage to be gained in

terms of future proofing, capital cost reduction, and ongoing operational costs if an agile

radio platform is used. The caveats are that technology needs to fully mature, and achieve

the needed cost and performance points. The specific trade-offs are dependent on the

context of deployment. We believe that this technology is appropriate for infrastructure

and longer-term deployments.

The requirements are for the agile radio platform to support the different frequency bands

of interest, and the potential networks of interest. At one extreme of this spectrum is a

completely general Software defined/cognitive radio, that supports a ultra wide frequency

bands of operation, and completely flexible baseband operation. At the other extreme are

fixed function radios. In between lie pragmatic points that reflect an engineering

compromise between what is cost-effective at a given point in time, while taking into

consideration the business requirements for the planned time scale(s) of deployment. For

example, some of the utilities believe that the life span of the AMI/DR infrastructure is on

35

the order of 15-20 years (at least!). It is the thesis at Southern California Edison (SCE) that

the Zigbee standard will survive over the course of their envisioned deployment lifecycle of

15-20 years. However, there is a distinct possibility that Zigbee itself may not be that long

lived, and that it might be useful to incorporate additional flexibility in a system that

supports, for instance, operation on different protocols in the 2.4 GHz band and the

provision for software upgrades to modulation schemes.

A more ambitious approach would be to be to expand this to a 2 or more frequency bands

of pragmatic interest, and consider the technical challenges that arise in building solutions

in this context. This is the approach initially explored in this project.

2.4.4.1. DR and AMI Requirements: Agility in the Short-to-Intermediate term

In the intermediate term, it is arguably useful to be able to support agility in the 2.4 GHz

bands, between protocols such as 802.11b/g (WiFi), 802.15.4/Zigbee, Bluetooth and others.

Additionally, frequency agility that spans the 800/900 ISM band, with support for Zigbee

and other baseband/protocol stacks is beneficial; there are several proprietary standards

that are also prevalent in these bands. Other emerging alternatives include Ultrawideband

(UWB) technologies for indoor communication, and WiMAX for external communication.

Indeed, the new generation of Bluetooth radios has adopted one of the UWB standards for

their radio technology [Bluetooth-UWB].

2.5. Demand Response Use Case Scenarios: Summary

We include here a synopsis of use case scenarios that are drawn from a vision for Demand

Response over the next several years.

2.5.1.1. Account Provisioning

When the customer calls the utility to activate an account, the customer service

representatives nominally go through an automated pre-service interview. The interview

gathers the basic information to support their billing process. It also asks a few very simple

questions to identify any medical or other special circumstances that might exempt the

customer from the Stage 2 involuntary curtailment of their HVAC systems. Identifying

customer locations with critical medical information also allows the utility to assign a

higher priority to preventative maintenance and outage incidents.

If it is indicated that medical monitoring equipment would be present, the customer service

representative can authorize a medical exemption to Stage 2 involuntary curtailment of the

customer’s HVAC systems. This authorization may cause a capacitor-activated radio

frequency identification (RFID) tag to be printed on the new customer Service Initiation

Checklist. This RFID tag may potentially be designed to be good for one use after which it

would become inactive and unusable. The RFID tag in this scenario functions like an

36

exemption key, however it would not become active until the PCT received its first

“Price/Test Signal”.

The Price/Test Signal was dispatched by the utility (or California ISO) several times each

hour. This signal provided the actual price included in the default CPP rate, so in effect it

acted like a real-time price. The signal also included location specific information designed

to allow the targeting of control and price/emergency actions on individual substations and

feeders, a time stamp to continually synchronize the PCT and data concentrators

supporting their advanced metering (AMI) data collection effort, and other maintenance

information used by utility field crews to support preventative and outage restoration.

The price signal information also was used to support utility and third party information

services like real-time customer displays of usage and actual cost.

The use of PCT’s and the ability to assign individual exemptions provided the utility with

tremendous flexibility to dispatch very limited HVAC curtailments, control a substantial

amount of load and generally avoid supply or congestion induced events that in the past

might require rotating outages. The involuntary HVAC curtailments dispatched in prior

Stage 2 alerts rarely reduced customer usage as much as the original air conditioner load

control programs.

Using basic occupancy information and the customer’s address, the utility may also be able

to call up the electricity usage history from her home or condo’s prior owner. This

information provided them with the information they needed to include estimated billing

and savings information on the Service Initiation Checklist they would send to the

customer.

2.5.2. Consumer Networking

The consumer electronics arena continues to be inundated with devices for a wide variety

of purposes. Examples include a rich spectrum of cell phones, audio and video players such

as the iPod™ and iPhone™, continually evolving home entertainment devices, new

variations of personal computers and storage appliances, as well as advanced home

automation controls and related appliances.

In addition to the proliferation of devices, there is increasing wireless connectivity and

sophistication in such connectivity.

A desirable top-level goal from a consumer’s perspective is to have seamless connectivity to

devices, and be able to access services and applications at any time, at any place, when the

need arises.

37

The technical requirements entailed by this include capabilities such as handoffs between

vertical and horizontal air interfaces, as well as for quality of support, service discovery,

personalization, etc.

2.6. End-to-End reconfigurability

It is increasingly the case that a user (consumer or application) operates in heterogeneous

environments, including heterogeneous communications systems, and using

heterogeneous devices.

� Examples of heterogeneous environments include: home, enterprise, automobile,

shopping malls, trains, airplanes, etc.

� Examples of heterogeneous communications systems include: a wide variety of

wired, wireless, and optical technologies, such as WiFi, LANs, DSL, Cable, 2G, 3G,

4G systems, DVB, mesh networks, etc. supported by a variety of management

systems and operations systems.

� Examples of heterogeneous devices include: a spectrum of mobile phones, PDAs

(Personal Digital Assistants), personal computers, consumer networking and

entertainment devices, etc.

The goal of a system that is reconfigurable from “End-to-end” is to provide a seamless

experience to the end user (consumer or application) by leveraging reconfigurability

(synonymously, agility) at different levels of the system.

38

1CKI ©

Utility/Service Provider

Internet

EnergyMeter

Sensors

HouseholdAppliances

HomeNetwork

Gateway

Node

Agile

DR

Node

Heterogeneous Environments

Heterogeneous Devices

Heterogeneous Systems

Dynamic

Resource

Management

Ubiquitous AccessOther Access

NetworksIP

Infrastructure

Multiple

Administrative

Domains

WLAN

WiMaX

4G

DVB

DAB

Others

Services

End-to-end Reconfigurability –Leveraging Agility & Enabling a seamless experience

Figure 9 End-to-End reconfigurability: Leveraging Agility and Enabling a Seamless Experience

We next elaborate on the system requirements for End-to-End system configurability.

2.6.1. Service Level Agreements (SLAs)

A service level agreement permits the parties involved to establish the minimum

performance criteria for service provision and the actions that will take effect if the service

does not meet these criteria.

System requirements related to Service Level Agreements that are suggested include the

following:

1. It that recommended that a reconfigurability service level agreement be established

between different actors of the system.

2. It is necessary that a roaming agreement exist between network operators. For

example, if some information needs to be conveyed between two elements in the

system, such an agreement would ensure that there would be no disruption in the

event of an intermediate network segment being replaced, or swapped in or out,

whether for business or technical reasons.

39

3. In the case of a software download within a network operator domain, it is

suggested that a Service Level Agreement should exist between the network

operator of the subscriber and the entity responsible for the software download.

4. An SLA agreement should exist between the network operator of the subscriber and

the software provider.

2.6.2. Security Capabilities

In case of upgrades of one or more elements of the system, the equipment reconfiguration

must be performed securely. Some system level requirements that are focused on security

are listed below.

� As an overarching requirement, it is essential that the reconfiguration process should be

performed securely.

� In the case of reconfigurable equipment reconfiguration, the subscriber must be

appropriately authenticated.

� In the case of a third party reconfigurable equipment upgrade, the reconfiguration

support service provider should be authenticated both by the equipment and the

subscriber.

� In the case of reconfigurable equipment upgrade, the equipment should be

authenticated by the entity responsible for the upgrade.

� In the reconfiguration process, all actors involved must be able to identify

themselves to each other.

� The equipment must be authorized to perform the reconfiguration process, either

implicitly or explicitly.

� (Privacy) The personal data, user profile and equipment profile stored in the

reconfigurable equipment must be protected from unauthorized access.

� There must be a way for the certification entity to be able to guarantee the software

is reliable, if required.

� There must be a process for the regulator(s) to investigate/evaluate the software, if

required.

� It must be possible to verify the origin of the software before the installation is

performed.

40

� The integrity of the software to be downloaded must be verified before installation.

� Prior to installation, it must be verified that the software operates properly.

� The detection-control mechanism implemented in the reconfigurable equipment

must not be modified by entities not authorized to do so.

2.6.3. Interference related Capabilities

Protection from the possible interference coming from badly reconfigured equipment must

be provided. The specific requirements related to interference mitigation are listed below.

� In the case of the existing configuration of the reconfigurable equipment not being

supported (permitted) in a certain area, the equipment must not start a transmission

until it has received or gathered information on what frequency is usable.

� There must exist, at the system level, a mechanism to detect if a reconfigurable

equipment is causing interference with other equipments or is operating incorrectly.

� There must exist, at the system level, a mechanism to correct behavior where

reconfigurable equipment is causing interference with other equipment or is

operating incorrectly.

� A mechanism must be provided to the network operator for disconnecting or

shutting down the transmission of any equipment.

2.6.4. Download Capabilities

There must exist mechanisms that allow the equipment to obtain a software module and

download it in order to reconfigure to a new configuration in a new wireless network. This

section lists some of the mechanisms that are required.

� A mechanism must be implemented that enables to ask for user download approval

before download.

� There must exist a mechanism that enables the software download to be billed to

the user.

� In case of a massive download, a mechanism should be provided to the operator to

perform the scheduling and control of the download process in order to avoid

network congestion.

� At any time of the download process, it must be possible to stop the process.

� Analogously, at any time of the download process, it must be possible to suspend

the process so it can be resumed later. As a complementary capability, it must be

possible to resume an interrupted download.

41

2.6.5. Equipment Reconfiguration

Reconfigurable equipment must be able to change its configuration including operating

parameters by means of software (such as frequency, modulation or transmitted power)

autonomously or without any external maintenance. Requirements in this context are listed

below.

� It is desirable that standardized (“Open”) interfaces exist that allow for the

development and provision of reconfiguration software for reconfigurable

equipment.

� Any user-specific preferences must be accessible by the user to modify the

reconfiguration possibilities.

� It must be verified that all the necessary software components for the

reconfiguration are available.

� It must be checked that the reconfigurable equipment will support the new

configuration before the reconfiguration process is initiated.

� The reconfiguration process of the network equipment must be performed and

controlled by the network operator.

� The software may require the approval of actors of the system before it is installed

in the equipment.

� After download, installation and reconfiguration, the successful completion of the

process must be verified.

� After successful installation, a test should be performed to check the new

configuration; the results of the test will confirm the new configuration (otherwise it

could initiate a recovery process).

� After the reconfiguration the reconfigured equipment must perform to

specifications with the rest of the system.

� In the case of equipment upgrade, the download must be rolled back to its previous

configuration if the upgrade does not succeed.

� The reconfigurable equipment must be able to return to a known stable

configuration.

� The reconfigurable equipment must be able to return to the original configuration.

� At any time of the reconfiguration process, it must be possible to suspend the

process so it can be resumed later.

� At any time of the reconfiguration process, it must be possible to cancel the process.

� The system shall include reconfigurable equipment management building on, and

compatible with, legacy device management.

� The capacity to reconfigure elements must not introduce performance degradations

compared to legacy equipment.

42

� The system should accommodate different classes of capabilities in the network

elements so as to perform optimal or near optimal reconfiguration.

� A reconfigurable element should enable the equipment manufacturer to be

upgraded, if so permitted by the user profile.

� Information related to equipment capability (both static and dynamic) should be

accessible by the network.

� Open interfaces must be provided for ensuring future evolution and/or migration of

the system.

� There must be a mechanism for handling service synchronization and optimizing

service access time during equipment reconfiguration.

2.6.6. Reconfiguration Management Capabilities

The end-to-end reconfiguration control management actions are assumed to be carried out

by a Reconfiguration Manager. The reconfiguration process might be initiated either by the

user equipment or by the network. The Reconfiguration Manager is a virtual entity that is

not required to be an independent component, but that can be conceptualized is used in

order to facilitate the expression of the requirements.

� The reconfiguration of protocol stacks supporting a mode of operation must be

performed dynamically, without shutting down the processor or the operating

system.

� Reconfiguration execution should be transparent to the user.

� Reconfiguration must be performed without any loss of information and without

user perceived disruption.

� Both user equipment and network should be able to initiate a reconfiguration.

� The reconfiguration process must be coherent with the various profiles associated

with the equipment/network/user/ etc.

� The reconfiguration process must be executed in non-interruptible steps, thus

enabling cancel/stop/resume actions at each step.

� Open interfaces should exist that allow for the development and provision of

reconfiguration software for the overall system.

2.6.7. Service Adaptation Capabilities

Active services can be adapted to changes in the network status (e.g. congestion) or

modification of the network equipment (e.g. reconfiguration), or alteration of the access

network used by a network component (e.g. vertical handover). Service adaptation may

cause reconfiguration in equipment in an attempt to avoid major disruption on the

executed service.

43

As a concrete example, if there is a lot of congestion in the 2.4 GHz band (due to a number

of simultaneously active devices, or noise in the channel caused due to a microwave oven

being used), an application or service may deem it appropriate to switch to a different

unlicensed band (such as the 900 MHz or 5 GHz band), or move to a licensed band such as

a cellular band. In such a case, the radio capabilities relating to the frequency bands of

operation need to be modified, as well as the protocol being used. Obviously, whenever

such a change is made, the concerned devices and processes must be notified and

“simultaneously” make the move.

Some of the important requirements in this context are listed here.

� Services must be dynamically adapted when a change in the system status occurs.

� Service adaptation may be context-driven, in that the service may trigger certain

adaptation actions exploiting context information.

� Based on the adaptation actions declared at its registration, context information

modification and system status change must be transmitted to the Service Provider,

in order to enable dynamical adaptation of the service.

� Service adaptation must be carried out in a manner that guarantees service

continuity.

� The user equipment should be able to establish simultaneously multiple

communication links using single or different radio access technologies in order to

access one or multiple services.

2.6.8. Vertical Handover Capabilities

Network equipment/elements should be able to move through different access networks

without loosing their active connections. For example, an application (such as transmission

of sensor data or metering information in the AMI infrastructure, or a voice call) must

continue to function independent of the underlying transport frequency and protocol being

used. Such vertical hand over can be equipment or network initiated. For example, the

gateway node may decide to communicate to the meter using a frequency and protocol that

is chosen locally; alternatively, the utility may choose to make this decision that must then

be obeyed by the AMI and gateway node.

� There must exist mechanisms that enable the transfer of the context of the

application/service for the seamless operation of 3rd party applications/services

when performing a vertical handover between different Network operators.

� The handover process must be completed in defined time slots depending at the

interfaces, without delays that may cause service interruption. Additionally, the

packet loss must be minimized. To accomplish this, different handover algorithms

may be available to be downloaded and executed.

44

� Handover decision(s) should be based on contextual information (user/paying

capabilities, user/Quality of Service demands, system capabilities, system load) so

that a compromise could be found among the various profile parameters.

2.6.9. Service Provisioning Capabilities

Service provisioning refers to basic energy, telecommunication and entertainment services,

as well as value added services offered by operators or independent value added service

providers.

Desirable system requirements in such a context are listed below.

� Open APIs should exist for third trusted parties to register and make their

software/services available to the users. This would enable, for example, energy

services, security services, monitoring services, etc. to be offered by third party

providers so as to the leverage the basic infrastructure that will be built up for DR

and AMI.

� Service discovery should take into account the user and equipment profile. This

suggests that the functionality required by an end user and the capabilities of

various devices will vary, and the mechanisms for finding discovering these

capabilities should be correspondingly malleable. For instance, these capabilities

can be part of the discovery process that is conducted.

� A mechanism must be provided to the Service allowing it to know the capabilities of

the available access networks.

� Services should automatically customize according to the capabilities of the

available access networks.

� As much as possible billing information for the services used by a user should be

incorporated in one single bill per service.

� There must exist a mechanism allowing the system to know the location of the

reconfigurable equipment.

� The system must support and implement a partitioning framework for

applications/service provisioning and connectivity provisioning

2.6.10. System Monitoring Capabilities

The equipment and network must be able to monitor the current state of system operation

(traffic, used spectrum, available technologies) in order to be able to estimate available

resources and to facilitate the 'best' use of existing and available resources.

� The user equipment and the network should be able to detect variations in the

operating conditions and act in order to make the best use of resources.

The user equipment and the network should be able to detect the presence of other radio

access technologies in a certain area.

45

2.7. Summary

The work described in this section has demonstrated that agile functionality is very useful

in the context of the emerging networks for Demand-response and Advanced Metering

Infrastructure. This is because they enable future proofing for RF technologies, and cost-

efficiencies by eliminating physical visits for the purpose of provisioning, upgrading, and

bug-fixing. The flavors of agility that are relevant in this context include: RF agility,

spectrum agility, and network agility. Based on representative use case scenarios, we

articulated some of the system level requirements that are useful in the long run to support

reconfigurable networks.

Research outcome

The stakeholder perspectives and use case scenarios investigated suggest that there is

substantial benefit to all stakeholders in having agile capability in radio nodes and the

overarching networks. In order to fully leverage agile nodes and networks, it is useful and

important to develop associated ancillary or related capabilities such as network and device

management and customer support, customer relationship management (CRM) etc. More

generally, we suggest enabling end-to-end reconfigurable systems, along with associated

support processes, systems, and tools.

Benefit to Stakeholders

From the perspective of network operators, system level reconfigurability enables a scalable

and reconfigurable infrastructure that optimizes resource usage. Having such an

infrastructure enables new applications and technologies to be offered more efficiently.

Additionally, it provides a high return on investment, and reduction of Capex and Opex

costs.

From the perspective of service and application providers, an end-to-end configurable

architecture offers open flexible platforms and associated execution environments. This in

turn enables the ability to deploy enhanced features, and a reduced time to

deployment/entering the marketplace.

The equipment manufacturers --including network equipment manufacturers-- benefit

from a wider market, and reusable components.

The spectrum regulators benefit from a consolidated framework wherein the wireless

environment should evolve. This includes easier access, better spectrum management, and

a context that supports follow-up and enforcement of ethical and technological rules.

Energy regulators can leverage configurability to implement demand response and energy

efficiency strategies to meet energy policy imperatives. It also reduces Capex and Opex for

46

the utilities, and provides a method to match time constants in deployment to the time

constants in technology evolution and business processes.

Finally, end consumers benefit from mechanisms to achieve a harmonious trade off

between comfort and cost of energy, seamless connectivity, and access to services.

47

3.0 PROJECT OUTCOME: AGILE RADIO FUNCTIONALITY

3.1. Introduction

Our research described in the preceding sections has demonstrated that Demand Response

networks can benefit significantly from the capabilities provided by network agility. We

next focus in greater detail on how such agile network capabilities can be achieved. Agile

radio nodes constitute a key building block for agile networks. The goal of the research

described in this section is to investigate and develop test-bed architectures for achieving

agile node functionality. The overall intent is to articulate a basis for more detailed design

exploration of agile radio nodes and agile networks (including cost-performance trade-

offs), and to develop a platform for prototyping specific architectures and implementations

that are relevant in a DR context. The actual exploration of specific designs suitable for

deployment is a topic for future work.

3.1.1. Section Outline

The notion of agile radio nodes is introduced in Section 3.2. Two aspects of agility, namely

agile (radio node) capability and the mitigation of interference with other nodes using

shared spectrum are discussed. The key components of an Agile radio node are described

in Section 3.3: these include an antenna (sub)system, an agile RF (Radio Frequency) Front

end, and a Base band processing engine. In order to enable exploration at the architectural

and application level, it is important to have a testbed platform that supports

experimentation at the proper levels of abstraction. We describe such an experimental

testbed platform (BEE2) in this Section. We also describe the associated framework that

enables the mapping of a configurable baseband engine onto the prototyping platform. The

design of an agile RF Front end for SDRs (Software Defined Radios) is described in greater

detail in Section Error! Reference source not found.. Section 3.5 elaborates on cognitive

techniques for interference avoidance, focusing in particular on interference mitigation

between UWB (UltraWideBand) and WiMax.

3.2. Agile Radio Functionality

3.2.1. What is Agility?

We use the term “agile radio” to refer to a radio platform that blends the attributes of

Software Defined Radios and Cognitive Radios.

A Software Defined Radio (SDR) is a radio whose communication characteristics are

defined and/or controlled via software. This basic ability can be leveraged to make a radio

adapt to different modulation schemes, and operate over multiple frequency bands.

“Cognitive Radios” are radios designed to enable opportunistic use of spectrum that might

48

be unused at any instant in time, although such spectrum might be pre-allocated to a

primary (class of) user other than the current one. The Federal Communications

Commission (FCC) defines a Cognitive Radio (CR) as a radio that can change its transmitter

parameters based on interaction with the environment in which is operates.

3.2.2. Two faces of Agility: Agile Capability and Interference Mitigation

The research discussed here focuses on two aspects of agile radio functionality:

� The first aspect of this research relates to the requirements and architecture of an

agile wireless platform that has the capability to communicate over more than one

frequency band and/or air interface standard (synonymously, wireless protocol),

and that is able to support new protocols and standards in the field. The goal of this

effort is to articulate the major components of an agile radio platform.

� The second aspect of this research relates to the investigation of interference effects

between a wide band technology that allows for opportunistic sharing of spectrum,

and the “primary users” in regulated bands that may overlap this band. Our

research focuses on characterizing and mitigating certain aspects of interference that

can arise in this context: this is the “flip side” of the capability to communicate. In

particular, the thrust of the research effort is to investigate mechanisms to mitigate

interference effects between UWB and WiMax technologies.

3.2.3. Agile Radio Platform Components

At a high level, the components of a radio include: an antenna subsystem, a radio

frequency (RF) front end, and a digital baseband processing module.

� An antenna (subsystem) that serves to transform energy between electromagnetic

waves and electrical signals.

o A system that is intended to process a wide spectrum of frequencies needs

an antenna (or an antenna subsystem) that is capable of sensing the swath of

RF spectrum that is of interest, and converting this to an electrical signal that

can be further processed.

o In targeting an agile radio platform that can function over a range of

frequency bands, the antenna system must in principle be capable of

receiving the frequency band(s) of interest. Depending on the desired

functionality of the system, a broadband antenna/RF front-end system may

be needed.

49

o Our initial architecture aims to target the 2.4 GHz frequency bands, with the

goal of expanding coverage in the 800-900 MHz frequency band.

� We have investigated two options in this context.

• The first uses one or more sets of antennas to span the

frequencies bands of interest.

• The second option uses a broadband antenna to cover the

entire band of interest.

� An RF Front end, that couples into the antenna (subsystem). The RF Front end for

the receiver module generates a digital output that is processed by the digital

subsystem. The RF Front end for the transmit module accepts input from the digital

baseband module and send the modulated signal to the antenna subsystem.

o Short-to-medium term options that we investigate focus on a set of RF front

end designs that span broad bands of frequencies centered around the

regions of interest.

o Longer-term alternatives that are in the early research stage involve filters

based on RFMEMs (Radio Frequency Micro-Electro-Mechanical systems)

technology.

� A Control and Digital baseband processing module, that couples in to the RF Front end.

o The research described here is focused on the design of an experimental

testbed, using a configurable processing engine as a building block.

Architectural elaborations are also described; however, specific baseband

implementations are beyond the scope of the current Phase I research effort.

o Longer-term alternatives are a cost-reduced version using custom silicon.

Mapping onto an experimental Platform

We employ a configurable platform for experimenting with the agile radio platform. In

particular, we leverage the Berkeley Emulation Engine (BEE2) that uses Field

Programmable Gate Array components (FPGA) to provide a scalable computing platform.

The baseband modulation schemes of interest can be mapped onto the BEE2 compute

engine. Antennas (or antenna subsystems) and analog front-end architectures that our

research has developed are interfaced to the BEE2 platform.

50

3.2.4. Interference Mitigation: Cognitive Technology for Ultra-Wideband/WiMax

Coexistence

Cognitive radios have been advanced as a technology for the opportunistic use of under-

utilized spectrum wherein secondary devices sense the presence of the primary user and

use the spectrum only if it is deemed empty. A distinguishing aspect of cognitive radios is

the ability to sense the primary user and modify their transmission parameters to avoid

interference to the primary.

One of the example use cases that is relevant in the context of future Demand-Response

scenarios is the use of WiMax for external wide area connectivity and the use of UWB or

similar related technology inside the house for short-range communication.

In this research, we explore the use of cognitive technology to enable the operation of ultra-

wideband (UWB) devices in WiMax bands. In this particular example UWB devices must

incorporate cognitive technology to detect and avoid (DAA) WiMax devices in certain

regulatory domains.

We consider various options for detection and avoidance. We then describe the obstacles

faced in achieving robust detection and avoidance with an on-chip implementation of basic

DAA functionality. This implementation is based on the energy detector and can reliably

detect WiMax uplink transmissions.

We investigate the operation of a single cognitive technology enabled UWB device with a

WiMax system. This interaction also highlights the problem of dealing with listen before

speak primaries where secondary transmission could interfere by denying the primary

access to the medium.

3.3. Agile Radio Nodes

In this section, we discuss agile radio nodes –network nodes that can be agile/flexible

in their wireless communication interface. The term “agile radio nodes” is used here as a

generic term that subsumes both Software Defined Radios [SDR] and Cognitive Radios

[CR].7 Both of these areas have been the subjects of much research, discussion and debate in

recent years, and Software Defined Radios in various incarnations are anticipated to have a

significant impact in the commercial arena over the next few years.

7 “Software Defined Radios” are radios whose communication characteristics are defined and/or controlled via

software (see Section 3.3.1), “Cognitive Radios” are radios designed to enable opportunistic use of spectrum

that might be unused at any instant in time, although it might be pre-allocated to a primary user other than the

current one.

51

We begin by briefly reviewing the notion of Agile Radio nodes in Demand

Response networks, focusing specifically on Software Defined Radio (SDR) nodes. We

introduce the various flavors of Agile Radio Nodes; comment on why and where they are

useful, and specifically on where they may play a role in Demand Response Networks.

3.3.1. What is a Software Defined Radio (SDR)?

Some of the basic components of a radio, as depicted in Figure 10, consist of analog

radio and human interfaces, along with an assembly of hardware (analog and digital) and

software components that perform various signal processing and general-purpose

computation tasks. A Software (Defined) Radio is a radio system whose functionality is

partially implemented in software.8 Examples where this technology is used include

cellular base-stations and access points, mobile terminals (cellular phones), as well as many

other emerging applications.

MODEM

More

Advanced

Capability

Messaging/Networking/GeneralPurpose

Processing

RF Front End Expanding digital component Analog/Human Interface

RF

Audio/Video

Human

Interface

Figure 10 Radio Components: Evolution of the Analog-Digital and Hardware-Software

Boundaries

3.3.1.1. Flavors of Software Defined Radios

In an attempt to categorize the spectrum of implementations of the general notion of

Software (Defined) Radios, the Software Defined Radio Forum9 (a consortium of groups

8 As a historical footnote, it is worth recalling that early radio systems were implemented entirely in hardware

with analog components. The Analog-Digital and Hardware-Software Boundary continues to evolve over time,

and as semiconductor CMOS technology evolves; the general trend is to reduce the number of analog

components (versus digital components), and to increase the software components (compared to hardware

components). It should be noted that no functional radio system can be implemented without hardware, and

that analog functionality is necessary at both the RF and the human interface.

9 www.sdrforum.org

52

interested in Software Defined Radio technology) has defined five tiers of “Software

Radios”, spanning the spectrum from implementations that employ exclusively hardware

components to systems that employ hardware components only at the edges, with software

being used for the rest.

Tier 0: Hardware Radio (HR). The radio is implemented using hardware

components only and cannot be modified except through physical intervention.

Tier 1: Software Controlled Radio (SCR). Only the control functions of an SCR are

implemented in software - thus only limited functions are changeable using software.

Typically this extends to inter-connects, power levels etc. but not to frequency bands and/or

modulation types etc.

Tier 2: Software Defined Radio (SDR). SDRs provide software control of a variety

of modulation techniques, wide-band or narrow-band operation, communications security

functions (such as hopping), and waveform requirements of current and evolving

standards over a broad frequency range. The frequency bands covered may still be

constrained at the front-end requiring a switch in the antenna system.

Tier 3: Ideal Software Radio (ISR). ISRs provide dramatic improvement over an

SDR by eliminating the analog amplification or heterodyne mixing10 prior to digital-analog

conversion. Programmability extends to the entire system with analog conversion only at

the antenna, speaker and microphones.

Tier 4: Ultimate Software Radio (USR). USRs are defined for comparison purposes

only. A USR accepts fully programmable traffic and control information and supports a

broad range of frequencies, air-interfaces & applications software. It can switch from one

air interface format to another in milliseconds, use GPS to track the user’s location, store

money using smartcard technology, or provide video so that the user can watch a local

broadcast station or receive a satellite transmission

10 Heterodyning is the process of “beating together” or mixing two different frequencies to obtain an output at

some other, related frequency. The mixing of two frequencies f1 and f2 results in the creation of two new

frequencies, one at the sum of the two frequencies mixed (f1 + f2), and the other at their difference (f1 -f2). A

superheterodyne receiver converts any selected incoming frequency by heterodyne action to a pre-selected

common intermediate frequency, for example, 455 kilohertz (AM receivers) or 10.7 megahertz (FM receivers),

and provides amplification and selectivity, or filtering.

53

The interesting developments from a pragmatic point of view are in “Tier 2

Software Radios” as described above; such radios are referred to as Software Defined

Radios, henceforth abbreviated SDRs.

3.3.1.2. Benefits of Software Defined Radios

In essence, Software Defined Radio (SDR) technology is a collection of hardware

and software technologies that enable reconfigurable system architectures for wireless

networks and user terminals. Software Defined Radios (SDRs) provide an efficient and

comparatively inexpensive solution to the problem of building multi-mode, multi-band,

multi-functional wireless devices that can be enhanced using software upgrades.11 As such,

SDRs can really be considered an enabling technology that is applicable across a wide

range of areas within the wireless domain. SDR-enabled devices (e.g., handhelds) and

equipment (e.g., wireless network infrastructure) can be dynamically programmed in

software to reconfigure the characteristics of equipment. In other words, the same piece of

"hardware" can be modified to perform different functions at different times. This allows

manufacturers to concentrate development efforts on a common hardware platform.

Similarly, it permits network service providers (also called “operators”) to differentiate

their service offerings without having to support a myriad number of terminal devices.

Finally, users of SDR enabled devices have a piece of scalable hardware that is at once

compatible at a global scale and robust enough to deliver a "pay as you go" feature set.

3.3.2. Software Defined Radios in Demand Response Networks

Figure 11 highlights some locations in a demand response network where Software

Defined Radios can be deployed. In particular, as suggested in the illustration, SDRs can be

profitably leveraged in sensor cluster gateway nodes and neighborhood gateway nodes, as

well as in the communication infrastructure. They are currently unlikely to be used in the

leaf level sensor nodes because of the extremely stringent constraints on cost and power

that are imposed on such nodes, and because of the absence of a predominant need for RF

agility in the end sensor nodes deployed within a home.

For example, a Software Defined Radio node that supports multi-mode operation can

support IEEE 802.15.4 [IEEE802.15.4] (and Zigbee Radios [Zigbee]), IEEE 802.11b (WiFi)

[IEEE 802.11] or Bluetooth all of which operate in the 2.4 gigahertz band. Multi-band

11 Multi-band operation refers to the ability to operate in multiple frequency bands. Multi-mode operation refers

to the ability to communicate using more than one protocol, e.g., Bluetooth and IEEE 802.11. Multi-functional

devices are capable of supporting more than one function, such as a combination of the functions associated

with a phone, camera and PDA.

54

operations can also be useful, and may be used to support commonly used frequency

bands such as 2.4 GHz, 5 GHz, and 800/900 MHz. These capabilities can be leveraged by

the gateway node for local area communications (using IEEE 802.11), sensor networks (e.g.,

using IEEE 802.15.4 and Zigbee devices), as well as backhaul communications using wide

area networks.

Cluster

Gateway

Node

Sensor

NodesSensor

Cluster

Network

Gateway

WAN

Client Data

Browsing/

Management/

Processing

Data Service

SCADA

Emerging technology

related to Software

Defined / Cognitive Radios

creates considerable

incentives for introducing

agility in some of the radio

nodes e.g. Gateways,

Wireless Infrastructure,

Terminals, …

SDR

SDR

SDR

Figure 11 Potential Roles for Software Defined Radios in Demand Response Networks

3.3.3. Antennas

The wireless revolution is creating new performance demands for antennas. Original

Equipment Manufacturers (OEMs) are increasingly requiring antennas that feature higher

gain, smaller physical size, and more versatility. We have explored the use of both regular

as well as broadband antennas in the design, in preparation for the experiments in a follow

on second phase of this project. While our initial experiments will use standard antennas,

we delineate below a representative example of a category of alternative antenna

technologies that are of interest in the context of this research.

3.3.3.1. Meander Line Antennas

Meander Line Antenna (MLA) technology supports a design that allows electrical coupling

of the fields of different segments of the antenna lines to significantly enhance their

performance. This enables one to combine smaller antenna radiating elements with a

meander line structure and geometry to achieve broadband performance in a small

envelope. The can yield an antenna that can resonate broadband and produce circular as

well as horizontal and vertical polarization and achieve higher gain—typically 1-4 dB

greater than traditional antennas.

55

The expectation is that such antennas are smaller and can be embedded directly within

various devices requiring a small form factor. In addition, they potentially feature better

gain and improved efficiency, resulting in longer battery life. Furthermore, MLA

technology enables the design of ultra broadband antennas capable of operating at multiple

frequencies and in a variety of modes.

Narrowband and Broadband MLA

MLA antennas may be configured into two distinct classes. The narrowband class exhibits

improved compactness for a given operating bandwidth. The broadband class enables

improved bandwidth capability, capable of covering multiple octaves without the need for

tuning. Both classes achieve performance very near to the theoretical Chu-Harrington

limit—indicating that they are approaching the smallest size for the exhibited bandwidth.

Volumetric Efficiency

One of the advantages of a Meander Line Antenna over more conventional antennas is high

volumetric efficiency. A comparative measure of an antenna’s volumetric efficiency (size) is

often expressed on a volume versus bandwidth graph in relation to the theoretically

determined limit. The so-called Chu-Harrington relationship establishes the limiting values

of bandwidth versus volume for a 100 percent efficient antenna—one that radiates all of the

power applied to its feed terminals. Compared to other antennas, the narrowband MLA is

demonstrated to provide more effective use of physical volume for narrow bandwidths (~

10–15%). This is easily seen in Figure 12 below.

56

Figure 12 MLA comparison of size versus bandwidth.

(The narrowband MLA antennas illustrated are at the leftmost portion of the graph indicating small

frequency bands associated with the various wireless services. The MLA antennas shown exhibit a

smaller physical volume for a given bandwidth as compared with other antennas shown on the

graph. The MLA achieves its performance gains through an effective and complete utilization of the

antenna volume.)

Multi-mode Operation

Another advantage of the MLA is the ability to achieve multi-mode operation in one

antenna structure. The MLA can be used in two radiation modes that can be excited

simultaneously or that can be individually selected electrically.

57

The fundamental mode is that of a monopole—the so-called “monopole mode” producing

a linear polarized radiation field resembling that of two closely spaced monopole antennas.

In the monopole mode, the primary antenna current is perpendicular to the antenna

ground plane.

The second mode of operation is the “loop mode” where the primary antenna current is

parallel to the antenna ground plane and the maximum radiation is perpendicular to the

ground plane. The loop mode can be used for satellite communications since one or the

other linear or circular polarization may be obtained through the use of a “crossed”

radiating structure.

Applications and Significance

MLA technology exhibits features suited to many applications, such as mobile handsets;

wireless data including laptops, PC cards and access points; and UWB.

Portable and Handsets

The MLA is well suited to portable wireless products due to its small size and performance

characteristics. Handsets often require worldwide GSM operation with Global Positioning

System (GPS) operating at 1575 MHz for location of the user in emergency (911) situations.

The broadband MLA is able to cover all three required bands simultaneously—having

coverage from 800-2500 MHz in a size 0.8 x 0.5 x 1.25 inches.

The lower limit of the bandwidth is determined by the antenna volume, which can be

reduced to 0.4 x 0.25 x 0.625 inches if the requirement for 850 MHz band coverage is

dropped.

An example of an antenna size designed to operate in the CDMA and GPS bands is 23 mm

(W) x 13 mm (L) x 8 mm (H). A normal antenna such as half-wave dipole or a monopole

antenna requires half-wave or quarter-wave length in physical antenna size. However, the

maximum dimension in the MLA antenna is only 23 mm which is less than 0.07 wave

length for the CDMA band (824~894 MHz).

Coverage of the different frequency bands is also possible with multi-band conventional

antenna designs. A disadvantage of currently used multi-band embedded antennas is

detuning when held in proximity to the body. It is common to observe resonance shifts

completely out of band with some embedded cellular handset antennas resulting in an

attenuation of up to 24 dB (measured). The broadband MLA, however, does not exhibit

measurable proximity detuning under similar conditions.

58

MLA handset antennas also feature reduced specific absorption rate (SAR) due to their

distributed near-field radiation. It has been shown statistically that signal strengths can be

increased on the average by as 2-3 dB with the use of embedded, reduced SAR antennas

such as the MLA. The advantage gained is due in part to a reduction of absorption of the

radiated signal by the human body. Studies show that conventional high SAR antennas,

such as the dipole and its derivatives, lose approximately 40–50% of their radiated signal to

absorption in the head.

The increased effective gain available with low SAR antennas provides a number of

advantages in addressing problems that are currently experienced by cellular users and

service providers. The advantages are:

� Improved reception quality at the cellular tower receiver results in

o Fewer dropped calls

o Improved customer satisfaction (lower churn)

� Lower power consumption in the handset

o Provides for longer battery life

o Allows smaller batteries to be used and increases the overall life of the

battery, resulting in lower cost to the end user

� Significant improvement of voice quality near the edge of the cell

o Provides better reception in border areas

� Potentially larger cell sites possible

o Decreased cost for service providers due to reduction in the number of cells

3.3.3.2. Triband Cellular + WLAN Antenna

The figure below illustrates a Meander Line Antenna that operates in the 800-

900/1800/1900/2400 bands spanning frequency bands of interest in the ISM, and cellular

band ranges. In contrast, many current generation cell phones employ multiple antennas to

cover broad frequency ranges.

59

Figure 13 Example Triband + Cellular antenna

3.3.3.3. WLAN 802.11a/b antenna

An example antenna that operates in the 2.44 GHz, 5.25 Ghz, and 5.8 GHz bands is shown

in the figure below.

Figure 14 Triband 802.11b/a/HiperLAN2 antenna

60

3.3.3.4. Ultra Wide Band Antenna

An example Meander Line Antenna shown below spans the 3.1-10 GHz range, and is useful

in the context of UWB applications.

Figure 15. UWB Antenna

3.3.3.5. Summary

We have summarized representative technologies that can be used to build antenna

solutions that can potentially reduce the size of devices and improve performance. While

we have detailed some of the options relating to Meander Line Antennas, advances in the

general area are enabling antennas to be developed that achieve higher gain, allow multiple

frequency operation, provide directional control over mobile handset emissions, provide

wider bandwidth for ever increasing data rate requirements, and are less obtrusive.

Other emerging technologies will be researched for a plausible follow on phase of this

project.

3.4. Agile Radio Testbeds. RF Front End

In the preceding sections, we have described the major components of an agile radio node,

and discussed some of the attractive emerging technologies in the realm of antennas. The

output of an antenna subsystem needs to be interfaced to an analog front end of the agile

61

radio node. In this section, we describe the research we have performed in designing a

Radio Frequency front end (RF Front End) that supports radio operation over a broad

swath of frequencies. We have integrated this RF Front End with a configurable digital

baseband engine to provide an overall platform for experimenting with and prototyping

agile radio nodes, and this work is also described in this section.

3.4.1. Main tasks

The key objectives targeted by the project are the following:

� Definition of the architecture and elements of an agile radio platform

� A mapping of these elements on onto a configurable testbed architecture that

provides a basis for experimentation in Phase II.

Ideally, a prototyping platform for agile radios needs to support the ability to have

different antennas, configurable RF Front ends, and a configurable baseband processing

engine (or compute platform). Furthermore, it must enable mapping specific designs onto

the platform in a reasonably painless fashion, and simulation of the system in a real time

with the ability to interface to real time analog interfaces. These simulations involve

significant amounts of real time complex digital signal processing is needed, and the need

to have a real-time (or near-real time) closed loop with the environment.

Our experimental platform leverages BEE2 [BEE2], a configurable computing platform that

is undergoing development at BWRC. Such platforms are necessary because the simulation

of an agile radio node behavior, let alone a network containing multiple nodes, cannot be

currently be done in anything approaching real time using PC-based platforms: a speed up

of at least a factor of 100-1000 is needed in order for this to achieved, even if the issue of

interfacing to real time analog signals is ignored.

The RF Front end is designed as an adapter card for the BEE2; this card communicates its

output to the BEE2 digital engine where baseband processing can be performed. Similarly,

on the transmitter side, the BEE2 reconfigurable computing engine is used for the baseband

computations, and the output is fed to the RF Frontend transmitter.

The longer term goal of the research (not within the scope of the current Phase I project) is

to develop a (set of) detailed baseband architecture(s) and identify components that can

eventually be mapped into an appropriate combination of software and silicon, so as to

facilitate subsequent cost reduction and volume deployment.

An illustration of the RF Front End system with test drivers and monitors is shown in

Figure 16.

62

Figure 16 An Illustration of the RF Front End and TestBed

A picture of the working hardware for the RF Front end is shown in Figure 17.

Figure 17 Prototype of a Broadband RF Front End

63

3.4.2. A Platform for Prototyping Agile Radio Testbeds Using BEE2

3.4.2.1. The BEE2 Platform

Figure 18Figure 18 illustrates BEE2, a configurable platform that can serve as a basis for the

digital signal processing and control computations that need to be performed in the agile

radio platform.

100BaseT

USB

40GBps

20GBps

18, 10GBps

InfinibandInterfaces

5, Virtex 2

Pro FPGA

4GB DDR RAM, 12.8 GBPs

Linux +

IP stack

Figure 18 Illustration of an Experimental Configurable Platform (BEE2)

The BEE2 platform is designed as a rapid prototyping environment for at/near real time

high performance DSP/RF systems. It enables systems (in particular, Digital Signal

Processing Systems) to be specified at a “high level” using a methodology based on

systems specified using Flow diagrams, Simulink, and code blocks, with a dual design flow

for mapping to FPGAs/ASICs. It has been successfully used for many chip designs, and

later used for high-end reconfigurable computing applications, such as DSP and ASICs

oriented towards radio astronomy applications, and as a platform for reconfigurable

computing.

The BEE2 Platform shown in the figure contains five FPGAs, 20 GBytes of DDR2, 64 GBytes

per sec of memory bandwidth, 180 GBits of full duplex IO bandwidth, serial

interconnections, transceivers, optical fiber connections, and 18 XAUI (10Gbit) ports. The

only high speed I/O is through the XAUI connection.

64

The BEE2 is highly scalable due to the reliance on gigabit serial I/O for inter-board

communication. This scalable system architecture allows the BEE2 to support a broad

variety of applications.

3.4.2.2. Agile Radio TestBed Components

This section describes a set of flexible wireless testbeds using the BEE2 (Berkeley Emulation

Engine 2), shown in Figure 19. Both wide-band and narrow-band testbeds have been

developed. The wide-band testbed is modular and scalable and includes an Interface

Breakout Board (IBOB) for connecting frontend boards to the BEE2, ADC, DAC, and analog

I/O boards. These frontends operate on two frequency bands of interest - one is in the

TV/ISM band from 500MHz-1GHz. The second band is at 2.45GHz with a bandwidth of

500MHz band. The narrow-band system has 2.4GHz reconfigurable RF modems. One can

connect up to 16 radios and antennas in parallel to the BEE2 system. Phase synchronization

and digital synchronization are provided with the narrow-band testbed to enable multi-

antenna testing. Both the wide-band and narrow-band testbeds have fiber link interfaces to

the BEE2.

BEE2

IBOB

Analog I/O

IDAC

IADC

Analog I/O

5 VP70 Virtex2 Pro18 XAUI ports

DRAM

Interface to

specializeddevices

Analog/Digital InterfacesTransceivers

Wideband Configurable TestBed (400-500MHz)

Specialized Interface for Narrow Band (20MHz) MIMO/Cognitive Radio

XilinxADC

DAC

Analog

I/O

Cognitive Radio Analog

Figure 19 Block Diagram of the Radio TestBed Components

This section provides an overview of the hardware, programming environment, and

applications of the narrow and wide-band testbeds using BEE2.

The agile radio front end testbeds connect to the BEE2. A fiber link interface is used for

connection between the BEE2 and radios. This fiber link allows radios and antennas to be

moved upto 1/3rd of a mile from the BEE2. The wide-band testbed is a modular design with

transceivers, an Interface Breakout Board, custom boards for wide-band, high speed ADC

and DAC, and an analog frontend. I/Q processing is done digitally. The narrow-band

65

system consists of a reconfigurable 2.4GHz radio modem. I/Q may be done in analog or

digitally.

3.4.2.3. The Wide-Band Testbed

The wide-band testbed targets broad-band radio applications by using the Interface

Breakout Board (IBOB) interface with high-performance ADC and DAC cards connected to

an RF front-end.

The BEE2 has limited I/O options, depending almost exclusively on the Gigabit serial

interfaces for high-bandwidth off-board I/O. To support specialized I/O needs, the

Interface Breakout Board (IBOB) was developed (Figure 20), providing an on-board Xilinx

2VP50 for preprocessing capability as well as multiple interfaces. The interfaces include

ZDOKs (40 LVDS pairs each running at 256 MHz or 40.96GBits per sec) and XAUI (20

GBits per sec full duplex, 10/100 ethernet, RS232, and 80x GPIO).

BEE2 XAUIIBOB

Figure 20 IBOB: Interface Breakout Board with XAUI connection to the BEE2 Processor Board

The custom ADC and DAC boards in Figure 21 connect to the IBOB through high speed

ZDOC connectors. Each ZDOC connector has 40 LVDS pairs, 36 differential pairs for IO

and 4 pairs for clock. The IADC has a high speed ADC with a sampling rate of 1Gsps (or 2

Gsps in interleaved mode). Each ADC has 8 bit resolution. The high speed DAC has a

sample rate of 1.2Gsps, a bandwidth of 550MHz, and a resolution at 10 bits.

66

IADC and IDAC

BEE2

IDAC

IADC

IBOB

IADC•1Gsps Sampling Rate, 2Gsps Interleaved mode•Dual ADC with 8-bit resolution•Atmel PN: AT84AD001B

•500mVpp Input

•Single-ended clock input

•3-wire serial interface, 16-bit Data,

3-bit Address

•Zdok interface to iBOB

IDAC•Sample rate 1.2Gsps•Full bandwidth of DAC: 550MHz •10 bit resolution •PN: Atmel TS86101G2B

•IDAC output: differential full scale output

voltage, 100 ohm termination, 2v P-P

•Integrated 4:1 Mux for easy interface to

FPGA

•Differential data inputs; LVDS pair Zdok

interface to iBOB

•Digital I/Q processing

XAUI

ZDOC

ZDOC

BEE2

IBOB

Cognitive

Radio

Analog

IDAC

IADC

Analog I/O

Analog I/OWideband Configurable

Figure 21 IADC and IDAC with high speed connections

3.4.3. RF Frontend System

The wide-band experiments include two bands of interest. One frontend supports TV and

ISM bands from 600MHz to 1GHz, and a second 500 MHz bandwidth front-end centers

around 2.45GHz. The 2.45 GHz ISM band front-end, used for sensing experiments, is

designed with a conventional mixer, whereas subsampling is used for the TV/ISM band

frontend.

CX4 or

fiber

Figure 22 RF Frontend Radio Boards: Analog I/O, IADC, and IBOB, which connect to BEE2 via

optical fiber.

67

3.4.3.1. Programming Environment

The highly reconfigurable BEE2 platform and related interfaces depend on a high-level

programming environment to fully utilize the capabilities of the testbeds described

previously. A block-diagram-based programming model was selected and extended to

include support for high-level operating system interfaces and debugging abstractions.

3.4.3.2. Programming Model and Support – Programming with Block-Diagrams

Traditionally, FPGA-based systems are configured using hardware description languages

such as Verilog or VHDL, requiring detailed knowledge of the reconfigurable platform.

Rather than requiring a wireless testbed user to learn low-level HDL programming

techniques, the Matlab Simulink block-diagram editor [Mathworks] was employed instead.

This environment is familiar to many architectural, signal processing, and hardware

designers, making it a natural unified environment for programming the BEE2 and related

system components.

The BEE Platform Studio [Chang] was developed around the Xilinx System Generator

blockset and tools, combined with the Xilinx EDK Embedded microprocessor design tools

[Xilinx]. A library of BEE-specific blocks (Figure 23) is used to provide a high-level

abstraction for several FPGA building blocks, allowing the designer to easily add

microprocessor register or memory interfaces to a signal processing design by selecting a

library component, and configuring the function using Simulink component property

menu selections.

Programming Model and Support

• Simulink Xilinx System Generator Library

• Custom BEE2 Library Blocksets

• Software programmable registers

• BEE Platform Studio

68

Figure 23 The Simulink Block-Diagram-Based Programming environment with library

components for microprocessor and I/O interfaces.

Once a design is described in Simulink, it can be compiled and mapped onto the BEE2 or

other platform using the BEE Platform Studio. The compiler sets platform-specific

parameters for the Xilinx System Generator tool flow, which is used to generate the

hardware description for the dataflow blocks. CPU interfaces are identified in the design,

and a set of files is generated with a complete description of the embedded CPU. This

description is automatically compiled to produce FPGA bit files and embedded software

header files.

3.4.4. The BORPH FPGA Operating System

Conventional FPGA design flows often require designers to manually develop

corresponding software interfaces to interact with the executing FPGA designs during

runtime. This effort is greatly simplified by the unified hardware/software run-time

environment provided by the BORPH operating system. By extending a Linux kernel,

BORPH provides a UNIX process and file system abstraction for the user-defined

hardware. User FPGA designs are executed in the BORPH run-time system as special

hardware processes that are identical to any other conventional UNIX process except they are

executed on FPGAs. User defined hardware constructs such as named registers, embedded

memories, and attached DRAMs can then be accessed through BORPH’s ioreg virtual file

system. For instance, assume that a user design contains a 32-bit register named

“FILTER_EN.” To set a bit in the register, the user can run the shell command:

$echo 1 > /proc/123/hw/ioreg/FILTER_EN

By using the underlying UNIX file system to represent user defined hardware constructs,

BORPH allows designers to easily access the running FPGA without the need to develop

any design specific interfaces.

On a BEE2 platform, up to four simultaneous hardware processes, one on each User

FPGA, are supported. Combining the block-diagram programming style in Simulink with

the convenience of BORPH, the designer is able to quickly develop FPGA applications

without becoming an experienced FPGA or embedded system designer.

69

The BORPH FPGA OS

Simplifies the interface to using the BEE2 boards

Mixed hardware/software inter-process communication with BORPH

Read/write hardware registers thru Linux filesystem

e.g. shell command:$cat data.in | hw_filter - > data.out

$echo 1 > /proc/123/hw/ioreg/FILTER_ENABLE

Linux + BORPH OS• /proc/<pid>/hw/ioreg• Socket

• Shared File• Pipe/FIFO• Signal

HWProcess

2

SW

ProcessA

SW

Process

B

HW

Process

1

Figure 24 The BORPH FPGA Operating System

3.4.4.1. BDB: The BEE Debugger

Debugging of a design is performed using a custom, integrated framework which utilizes

debug components inserted into the hardware netlist in combination with an external

remote user interface. Layered on top of the BORPH operating system, the designer can

use the BEE Debugger, BDB to easily add hardware trace variables to the Simulink design,

and record related signal activity at near real-time speeds to on-board DRAM during

design operation. In addition, though BORPH, the user can control the debugging process

from any location over the network. Beyond the simple convenience of being decoupled

from the hardware location, this also allows debugging to take place in the original design

environment (i.e. Matlab/Simulink), which greatly improves bug detection and data

analysis compared to traditional hardware capture techniques.

70

Master debug

controller

Control FPGA

User FPGA

BORPH

User

Design

Variable Logic

Clock

BufferControl

Network

DRAMBreakpoint Logic

Automatic generation of in-fabric variable networkRead/Write access to all data

User-defined assertion checking

Integrated core debug controllerThrottles user design clock for manual single-stepping

and automated breakpointing

Off-chip interface via BORPH

Remote MATLAB debug clientAllows back-annotation to Simulink design

Figure 25 BDB: A system with inserted debugging trace variables and debug controller block

3.4.4.2. Cognitive Radio

Cognitive radios have been envisioned as a mechanism for the opportunistic reuse of

spectrum. These radios “sense” for the presence of the primary user and use the spectrum

only if it is deemed empty. If a frequency band is deemed empty, these radios can transmit

in the band at a power level which ensures minimal interference to the primary radio. This

kind of reuse is illustrated in Figure 26, where PU1-4, are primary users using their

respective bands. CR1 is able to transmit in the empty band between PU3 and PU4. Compare

this to the transmission of CR2, CR2 is unable to sense for the presence of PU2 and starts

transmission. This transmission interferes with PU2 and is undesirable.

Cognitive Radio:

•Sense the spectral environment over a wide bandwidth

•Transmit in “white space” & Adapt bandwidth and power

•Detect if primary user appears

•Move to new white space

PS

D

Frequency

PU1

PU2

PU3

PU4

CR1

CR2

Primary

Cognitive

Figure 26 Cognitive Radio: sensing the spectral environment

71

As the discussion above illustrates, one of the key aspects of a cognitive radio is the ability

to reliably detect the presence of primary users. Furthermore it should do this while

ensuring that its ability to find an empty band is not diminished (One can imagine a

cognitive radio that always says that a primary is present. Such a radio always ‘detects’ a

primary but is never able to use the band). Using the testbed described earlier, we

investigated various aspects of cognitive radio operation.

Performance of various single band sensing algorithms:

The testbed was used to measure the performance of various single radio sensing

algorithms: Energy detection, Coherent detection and Feature detection. The

experimentation used the Agilent Signal generator to generate an appropriate primary

signal. This signal was captured by the using the 2.4GHz narrow-band frontend. Since the

narrow-band front-end has two antenna ports, one of the ports was always terminated and

used for noise measurements. The strength of the primary was varied and the number of

samples needed for achieving a target probabilitiy of missed detection and probability of

false alarm was measured. These experiments allowed us to verify/observe a number of

issues with detection:

� For energy detection the number of samples needed to achieve target detection

performance scales as O(SNR-2). For pilot detection this scaling is O(SNR-1)

� The energy detector suffers from noise uncertainty. If the PSD (power spectral

density) of noise is not known exactly, then the target performance cannot be met

irrespective of the number of samples used [Cabric et al].

� The FFT (Fast Fourier transform) acts as a partially coherent detector for sinusoidal

primaries.

� Coherent detector performance is limited by frequency mismatch between the

transmitter and receiver.

� Feature detector performance is also limited by frequency mismatch between

transmitter and receiver. This can be overcome by using a two stage detector

[Tkachenko et al].

Performance of cooperative sensing

Since single radio performance is limited by noise uncertainty, multiple radios can be used

to improve performance. To conduct these experiments we positioned the receiver at a

number of places in the BWRC as shown in Figure 27. At each location a number of

measurements were made a few wavelengths apart. Cooperation among radios a few

wavelengths apart allowed us to get diversity over multipath. Cooperation among radios

further apart allowed us to get diversity over shadowing.

72

Cognitive Radio: Experimental Setup

Location (11,9)

Location (16,3)

Central combining and processing

Fiber provides 1/3 mile separation between radios and platform

Sensing radio

Sensing radio

Sensing PHY/MAC processors

Indoor wireless

experiments

inside BWRC determining

spatial sensing

characteristics

54 locations on a 2m by 2m grid

BEE2

IBOBIDAC

IADCAnalog I/O

Analog I/O

Analog

I/O

Cognitive Radio Analog

ADC

DACXilinx

Figure 27 Experimental Cognitive Radio Set up to measure gains from cooperative sensing

Performance of multiband sensing

For a single radio, we need to set the target detection level to be very low in order to ensure

that we can detect the signal even when the cognitive radio is severely shadowed. In

multiband sensing we aim to determine the shadowing environment of the radio and then

set the detection level dynamically. To do this we utilize the fact that multiple transmitters

are positioned on the same place tower (especially for TV channels) and that shadowing

across frequencies is highly correlated. Thus a detector can sense for channels on nearby

frequencies and use these channels to dynamically set the detection level for the channel in

question.12

3.4.5. Agile Radio Testbed: Summary

This section has described a flexible wireless testbed with associated software support, I/O,

and network level support. The BEE2 programming environment includes Simulink that is

used as the base programming model, BORPH as the run-time OS, and BDB for debugging.

We use specialized library modules for our hardware abstraction. For testbed interfaces,

high speed gigabit per second digital interfaces are provided by XAUI connectors. The

platforms provide both wide-band and narrow-band RF frontends in both the TV and ISM

12 We are currently in the process of verifying the multiband algorithm using measurements of TV channels in

the bay area. For this we are utilizing the wide-band frontend which allows us to measure all TV channels

between 500MHz and 800MHz. The measurements are being made at various locations in Berkeley. At these

locations we can measure the TV channels from Mt Sutro and Mt San Bruno.

73

bands including ADCs and DACs. The Interface Board, IBOB, provides multiple high

speed connection options for connecting various frontends to the BEE2. For emulating a

network of radios, we can connect upto 18 radios to the BEE2 via the optical connections.

3.4.5.1. Software Defined Radio RF Front End (RFFE): Research Tasks

The research tasks performed in this context included the following:

1. Design of SDR RF Front End Analog Hardware

We have a working RF frontend which consists of connectorized RF Blocks such as

mixers, filters, amps, etc.

2. Design of SDR Digital Hardware.

We have designed, built, and tested the ADC (Analog-to-Digital converter), DAC

(Digital-to-Analog converter), IBOB, and BEE2.

3. Design of the SDR Software skeleton.

o We have created Simulink designs for both receiving and transmitting.

o The receiver simulink design includes receiving an analog signal from the

RF analog frontend, processing thru an ADC, brought over a ZDOC

connector, and into a Xilinx for baseband processing on the IBOB.

o The transmitter design includes the processing and control of the signal

from the IBOB’s Xilinx, thru a ZDOC connector onto a DAC board. The

signal is then processed thru the DAC board. The analog signal is the

output of the system.

o We have used existing simulink libraries in our matlab designs.

o We use BORPH for system control. Software programs have been written to

control the system parameters such as the clock. We produce plots of the

system frequency response. BOTPH provides mixed hardware/software

inter-process communication.

4. Loop Test of the System

o A loop test of the system was successfully completed. This included a

received analog signal from the RF frontend. The analog signal was then

processed thru the ADC, across a ZDOC connector, onto a Xilinx FPGA on

the IBOB. From the Xilinx the digital signal was processed across a XAUI

connector onto an optical transceiver and optical cable. The other side of the

cable contained another optical transceiver where the signal was then

processed onto another Xilinx on an IBOB board. From here, the signal was

74

routed onto a DAC board thru a ZDOC connector. The output of the DAC

was the analog signal which matched the input analog signal.

Figure 28 Data flow and Input/output for the Prototype tested

3.4.5.2. Front End Analog Hardware

The protocols that are currently being considered in context of Demand-Response

and Home Area Networks include WiFi and ZigBee, which lie in the 2.4 GHz and

900 MHz ISM bands. As a consequence, we selected the following frequency bands

for an initial experiment in the design of the RF Front end analog hardware.

� 2.45GHz band: 2.2GHz – 2.7GHz Receiver

� 2.45GHz band: 2.2GHz – 2.7GHz Transmitter

� TV + ISM band: 600MHz - 1GHz Receiver

� TV + ISM band: 600MHz - 1GHz Transmitter

This choice has the benefit of including the bands of interest for DR/HAN contexts, while

also allowing bands that overlap with Analog TV and WiMAX.

The details of the front end analog hardware design are described in the Appendix.

IDAC

Existing

Board Atmel

TS86101

IBOB

Existing

Board Xilinx

XC2VP50

IBOB

Existing

Board Xilinx

XC2VP50

Analog

Receiver

IADC

Existing

Board Atmel

AT84AD001

Analog

Transmitter

Source

Scope

75

Figure 29 2.45GHz +/- 250MHz Receiver Design using minicircuits

2.45GHz +/-250MHz Receiverwith iADC and iBOB

Figure 30 Receiver with iBOB and iADC

The illustrations above indicate the SDR broadband front designs that have been coupled

into the system.

Front End Matlab Designs

For both the receiver and transmitter designs, the blocks used were assembled from the

Simulink Xilinx System generator library, custom BEE2 library blocksets, and software

programmable registers.

76

3.5. Cognitive techniques for Interference avoidance

3.5.1. Abstract

Cognitive radios have been advanced as a technology for the opportunistic use of under-

utilized spectrum wherein secondary devices sense the presence of the primary user and

use the spectrum only if it is deemed empty. The distinguishing aspect of cognitive radios

is the ability to sense the primary user and modify their transmission parameters to avoid

interference to the primary.

In this section we explore the use of cognitive technology to enable the operation of ultra-

wideband (UWB) devices in WiMax bands. In this particular example UWB devices must

incorporate cognitive technology to detect and avoid (DAA) WiMax devices in certain

regulatory domains.

We start by discussing various options for detection and avoidance. We then describe the

obstacles faced in achieving robust detection and avoidance with an on-chip

implementation of basic DAA functionality. This implementation is based on the energy

detector and can reliably detect WiMax uplink transmissions. Finally, we describe an

empirical set up for the operation of a single cognitive technology enabled UWB device

with a WiMax system. This interaction also highlights the problem of dealing with listen

before speak primaries where secondary transmission could interfere by denying the

primary access to the medium.

3.5.2. Introduction

Ultra-wideband (UWB) technology is termed as such since it occupies large swathes of

spectrum and uses very low power to communicate. UWB’s intended use is in the 3-

10GHz bands for short range (~10m) communications for implementing Wireless Personal

Area Networks (WPAN) [WiMedia Specs]. WiMax (Worldwide interoperability for

Microwave access), on the other hand, is the commercialization of the IEEE 802.16 standard

and is meant to provide high speed wireless data services over a much wider area (~5

miles) [Abichar et al 2005] . The target bands for WiMax deployment are the 2.4GHz,

3.5GHz and 5.8GHz bands. The 3.5GHz band is free in most countries except the United

States. Operation of WiMax in the 3.5GHz band is susceptible to interference from UWB

devices operational in band group 1 (3.168GHz to 4.752GHz) as per the WiMedia

specifications [WiMedia Specs]. This is particularly true in Europe, Korea and Japan as

illustrated in Figure 31.

The usage models of WiMax and UWB are both centered around laptop cards and hence an

UWB device could potentially interfere with reception at the WiMax Customer Premise

Equipment (CPE) (See Figure 32. Potentially disruptive interference between WiMax and

77

UWB occurs when the WiMax equipped Customer Premise Equipment (CPE) is in close

proximity of an UWB communication pair. (See Figure 32). However since the two services

occupy different spatial scales, if the transmissions of UWB are properly coordinated they

could complement each other. The traditional regulatory mechanism to handle interference

is to separate contenders in space or in frequency. Thus regulators would impose artificial

limits on transmissions to minimize interference. This approach precludes dynamic

spatial/temporal reuse of the spectrum. Furthermore, with all frequency bands being

allocated multiple times over, new spectrum is not readily available for such allocation.

Thus by declaring that all new users of the spectrum are secondary users and requiring that

they must detect and avoid (DAA) the primary user, the regulators are opening up

spectrum for opportunistic use. In the absence of DAA functionality, UWB devices would

have to forfeit the band designated as ‘DAA required’ in Figure 31 which would greatly

reduce the spectrum available for communication.

In this section, we first describe the detection problem, profiling both downlink and uplink

detection. We then explain various avoidance techniques and justify the adopted approach

of using a ‘notch filter’. Following this, we explain on-chip detection functionality as well as

the various practical problems in implementing robust detection. Finally, we describe

research plans for investigating coexistence results with an actual WiMax system.

78

Figure 31. Overlapped frequency allocation for WiMax and ultra-wideband (UWB)

79

Figure 32. Potentially disruptive interference between WiMax and UWB occurs when the WiMax

equipped Customer Premise Equipment (CPE) is in close proximity of an UWB communication

pair.

The details of the design and research related to Detection and Avoidance are contained in the

Appendix.

3.5.3. Example configuration for cognitive radio engine

Figure 6 shows the infrastructure required to connect the UWB chip to the BEE2 board. The

IBOB (Infiniband Break out Board) provided the optical connection from the IBOB board to

the BEE2 board.

High speed

Parallel(ZDOK)

Infiniband

Break out Board(IBOB)

BEE2

Infiniband connection

WiMedia complaint

RF/Baseband

UWB chip with DAA

Figure 6: BEE2 with the Infiniband Break-out board (IBOB)

80

3.6. Summary

3.6.1. Summary of Accomplishments

Agile radio nodes constitute a key building block for agile networks. This section

summarized research related to platform for implementing Agile Radio functionality,

leveraging configurable building blocks.

The key components of an Agile radio node include: an antenna subsystem, an agile RF

Front end, and a Base band processing engine.

� We identified technologies that enable compact, small sized antennas that are

capable of wideband performance; an example of such a technology is the class of

Meander Line Antennas. Advances in this arena will enable antennas to be

developed that achieve higher gain, allow operation over multiple frequencies,

provide directional control over mobile handset emissions, provide wider

bandwidth for ever increasing data rate requirements, and are less obtrusive.

� We described the design of an agile RF Front end for SDRs (Software Defined

Radios). Further, we also presented the details of a laboratory prototype for a

broadband RF Front end. As a demonstration, we have implemented a template

that spans the 700MHz – 1GHz band; a design for the 2.2-2.7 GHz band has also

been developed.

� We also defined a configurable platform that provides a basis for prototyping

architectures of agile radio nodes. Specifically, we have described a prototyping

platform that leverages BEE2, a reconfigurable compute platform. More broadly,

such a platform can be augmented to serve as the basis for experimenting with agile

networks by emulating networks that contain multiple nodes.

In addition to designing a platform for enabling agile radio capability, we also investigated

the mitigation of interference with other nodes that may be using shared spectrum. In

particular, we have developed cognitive techniques for interference avoidance, focusing in

particular on interference mitigation between UWB and WiMax.

3.6.2. Suggestions for Follow on Research

The prototyping platform we have developed here can be used as the basis for further

research and for prototyping solutions that are important in the DR context. For example,

the goals here include designing specific radio nodes and networks that support DR

requirements for envisioned deployment scenarios. In particular, this would entail

identifying the spectral ranges of interest, the protocols of interest, and implementing these

requirements on the RF and baseband platform with a view to investigating the feasibility

of certain cost-performance points. In addition, it would involve implementing interfaces to

81

sensor networks and the DR/AMI/network infrastructure. More ambitious programs can

also be developed to leverage the research we have described here.

In summary, our research discussed here underlines the usefulness of network agility in

the DR/AMI/HAN context, and provides a basis for developing a more specific prototyping

effort in the next phase of research.

82

4.0 INTERFACING AGILE NETWORKS

4.1. Introduction

When agile nodes and networks are introduced into the context of Demand-

Response/AMI/HAN systems, it is important to be able to amalgamate them into the

overall network architecture. In order to do this, it is necessary to have an interface for the

Demand-response Services network on the one hand, and to the Sensors and sensor

networks that may be deployed at home or in the business premises. This is depicted in the

figure below. This section delineates the nature of these interfaces, and defines an

architecture that incorporates the interface.

Agile

Gateway

Node/Network

DR/

Network

Services

Interface

Sensor

Network

Services

Interface

Figure 33 Interfacing Agile Networks

4.2. NETWORK SERVICES AND MANAGEMENT

A utility or third part service provider has a need to

� Define the Demand Response and other energy/information services that are offered

to a customer;

� Provision the specific service that is chosen by the customer;

� Provide support for the service, as well as associated consumer products and

infrastructure for the lifetime of the service.

o This requires supports for related activities such as monitoring, update,

management, and software download.

83

Service definition is normally done by the utility service providers, using conventional

strategies that take into account customer requirements, use case scenarios, priori

experience, and business case projections.

The service provisioning process normally involves installing (and/or enabling) the

appropriate set of devices/functions in the devices. A familiar analogy in a communications

context is the process of provisioning a cable or phone service. When a new service is

requested, the Set-top box/phone (client terminal device) is installed at the customer site,

and then registered into the back-end system and network data bases. In addition to the

basic ability to receive video, place and receive calls, each set-top box is associated with a

variety of attributes (or service parameters). In the case of phone service, these might

include, for example: local area calling, vs. local and long distance, the specific rate plan

assigned to or chosen by a specific customer, etc. In addition, at the time of initial

provisioning or at a subsequent time, the phone company can enable or disable various

features such as Caller ID, 3-way calling, etc. In the case of cable TV service, this may

include the ability to download Pay-per-view movies, of a certain type, up to a limited

budget, etc.

In a similar fashion, when the consumer is initially provided a demand response service,

the service needs to be provisioned. This may involve, for example, initiating DR capability,

coordinating meter readings, setting policies, etc. The menu of services may change over

time. Further, new services/capabilities and value added features may be added over time,

e.g., the ability of a customer to view energy usage, report problems/outage. It is

conceivable that non-energy related services, such as security services, could be provided

by a utility, although this is outside the scope of this research.

4.2.1. Network Services Delivery

Network Services Delivery and Management involve the delivery, provisioning,

deployment and ongoing management of network services, and in our case, DR related

services.

This is enabled via a software platform & a basic set of services that are provided via an

abstracted interface. This can be an Application Programming Interface (API) or a web

services interface. Components of this API will be running on the utility/service provider

network side, and in the home network.

84

Webpad/

Browser/

PC/ TV/ PCT...

Internet

Gateway

Utility/ …

Service Delivery

Platform (SDP)

Meter

Home Gateway

(Gateway running

SDP)

Figure 34 Example deployment of Service Delivery Platform (Software)

4.2.2. Platforms hosting the Service delivery components

To enable managed services at the point-of-use, such as a home or automobile, we

need a “gateway” device, capable of storing and running service application software. The

Gateway may be a general-purpose computer (such as a PC), a special purpose device

(such as a residential gateway, set-top box, media server or automobile multimedia

gateway), or a virtual resource in the operators network.

4.2.3. Requirements/attributes of a service delivery platform

The desirable capabilities of a network service delivery platform are that it should:

� Enable services gateways that need zero-administration

� Support secure remote operation by a service aggregator

� Enable multiple services to cooperatively share a common services gateway

� Support any combination of remote and local networks

� Be usable in home, small business, home office, industrial applications

(additionally, in the automobile).

Additional requirements of a platform include the following:

� Reliability. Large scale deployments fail without very high reliability

85

� Portability. The platform must be portable across different hardware platforms, and

have an open architecture. This enables third party developers to create additional

components and services.

� Adaptability. The platform should enable the configuration to adapt to users and

operator needs over time

� Security. The platform should protect service providers from each other, and from

the user and malicious intruders.

� Quality of service. The platform should be able to guarantee a certain quality of

service.

� Scalability. Different contexts and applications may impose very different

configurations for their deployment of a framework. The platform must be

adequately scalable to support such variability.

4.2.4. Lifecycle management support

The service platform should provide support for the entire life cycle of the service process.

That is, it should enable the service to be installed, started, stopped, updated, and

ultimately uninstalled if needed.

� There should be a provision of having a registry of services available, and of those

provisioned. Appropriate notification mechanisms should enable both human and

programmatic interfaces.

� For scalable deployment, Package and version management of software on the

devices should be supported.

� An open remote management architecture is useful, because it can leverage the

ability to interface with other management modules.

� A strict separation of specifications and implementations is critical to maintain in a

platform, since over the lifespan of any such system, there will inevitably be

multiple implementations involved.

4.2.5. Service Delivery Platforms: Background

The term Service Delivery Platform (SDP) refers to a recently embraced architectural style

applied to telecommunications infrastructure problems. We are here suggesting an

expanded usage in the context of Energy and related information services, including

Demand Response. The goal of a Service Delivery Platform is to enable rapid development

and deployment of new converged services, from basic phone services to complex

audio/video conferencing for multiplayer games (MPGs), to Energy and other value added

86

services. SDPs typically provide a service control environment, a service creation

environment, a service orchestration and execution environment, and abstractions for

media control, presence/location, integration, and other low-level communications

capabilities.

It is possible for a service delivery platform to feature a unified directory of customers

which provide a metadata architecture for all existing customer databases, including

business, consumer, broadband or mobile. This can be leveraged in the context of DR and

other Energy services. SDPs are applied to both consumer and business applications, with

the latter set often focused on the integration of telecom and IT capabilities. Although traditional telecommunications companies like Nortel, Avaya, Ericsson and

Alcatel-Lucent have provided communications integration interfaces and infrastructure

since the early to mid 1990s, the cost-saving success of IP-based open systems, such as

VoIP systems as replacements for proprietary PBX systems and desktop phones, has

prompted a shift in industry focus from proprietary systems to open, standard

technologies. This has also opened the door of the telecom closet to traditional IT vendors

like IBM, HP, Oracle, Redhat and BEA Systems who are developing or have developed

SDPs of their own. This strong focus on open environments has also given systems

integrators the opportunity to offer turnkey pre-packaged, integrated SDP solutions. In

addition new consortia of telecommunications new software product companies are also

emerging. By offering pre-integrated software products consortia offer an alternative

means for operators to create SDPs based on key product elements - such as convergent

billing and content/partner relationship management.

Suggested deployments can leverage open platforms as well as Java based platforms for

applications that are not that real-time sensitive.

4.3. SENSOR NETWORK SERVICES

4.3.1. Summary

A sensor network interface should enable a user (or application) to access the services

provided by a sensor network. It is desirable, indeed important, for such an interface to be

independent of the specific implementation employed, and in particular the

implementation details of the sensor hardware and software; this is to support a

heterogeneous set of sensors, and to allow for evolution in the sensors that are deployed.

There are significant benefits to making such services be available via a standard web

services interface. At the network level, it is useful to leverage a protocol such as IPv6, since

this provides for addressability at the sensor node level; using standard IP protocols also

enables a plethora of existing management tools to be used.

87

From a systems perspective, the services provided by a sensor/actuator network should be

easily accessible and manageable by users/other programs. Historically, given the manner

of evolution of sensors, sensor platforms and sensor networks, most applications have

tended to use customized hardware platforms, embedded software and custom drivers. It

was then recognized that it was important to have an operating system abstraction, in order

to ease some of the pain of programming individual nodes at the assembly language level.

As a result of this, operating systems such as TinyOS [Culler et al] have been developed,

and ported to a number of hardware platforms. Industrial counterparts of such operating

systems also continue to evolve. It is nevertheless obvious that the abstraction needs to be

both standardized, as well as raised to the next level. Potential ways to do this are to

abstract the services offered at the level of sensor networks (rather than individual sensor

nodes), and adopt a standard protocol for communicating with such networks and services.

Low-power wireless personal area networks (LoWPANs) comprise devices that conform to

the IEEE 802.15.4-2003 standard by the IEEE [IEEE802.15.4]. IEEE 802.15.4 devices are

characterized by short range, low bit rate, low power and low cost. Many of the devices

employing IEEE 802.15.4 radios will be limited in their computational power, memory,

and/or energy availability.

For completeness, we provide in an appendix a brief overview of LoWPANs and describe

how they can benefit from IP and in particular IPv6 networking. (Our treatment derives

from ongoing standards body activities in the IETF and other organizations.) It describes

LoWPAN requirements with regards to the IP layer and above, and spells out the

underlying assumptions of IP for LoWPANs. We also identify some problems associated

with enabling IP communication with devices in a LoWPAN, and goals to address these in

a prioritized manner.

88

5.0 Benefits to California

We summarize below the potential impact of the proposed work on Operating and Capital

Expenditure savings, benefits in the context of Demand-response networks, consumer

benefits, and benefits to the California Electric market.

Operating Expenditure Savings

It is a well-established fact in the telecommunications community that a visit to a customer

site by a maintenance/service professional for the purpose of installation or maintenance—

sometimes referred to as a “truck roll”—entails a cost of $100-200+ per visit (depending on

various associated costs and overhead). It has also been observed that for consumer related

services such as DSL, Cable modems, etc.—and utility DR/PCT/AMI deployments fall into

this category for residences—operational costs that involve more than one site visit on

average adversely impact the business case for such deployments, often to the point of

making them infeasible in practice (unless the customer is made to pay for these costs). The

implication of this observation is that unless technology similar to that proposed in this

project is leveraged in the context of DR/AMI, the business cases for deployments in the

arenas of demand response and energy efficiency may be severely impacted, and impede a

cost effective implementation of energy policy imperatives in the state.

Capital Expenditure Savings

The ability to remote provision services and upgrade capabilities after deployment avoids

the expense inherent in procuring and provisioning new premises infrastructure

equipment such as gateways and control thermostats. This can results in significant

savings, which can again be passed through to the consumer.

Benefits for Demand-Response Networks

Demand-Response Networks accrue several direct benefits from employing agile

communication nodes, including

� The ability to support configurable, software-defined radio nodes. This makes it

possible to ride the (reducing) cost curve in hardware deployments in new

buildings and homes, while enabling software service deployment platforms to be

reused. Additionally, this enables

o Software download of new, enhanced functionality, specifically (1) radio

functionality and (2) service functionality;

o Policy defined management and operation of DR networks.

o The ability to leverage evolving new technology in agile radios.

� The ability to have access to a diversity of wireless channels, and use the best

available wireless/network channel.

89

� Improved redundancy at the system and network level, by virtue of having access

to more than one transit network for communication. These options can be used to

transmit and receive data, as well as to transmit and receive control signals.

� The ability to deploy and manage new value added services across such networks.

� The ability to adapt the network dynamically to reflect business processes and

network policy.

� The ability to leverage new spectrum policy that is projected to evolve significantly

over the next several years.

� The ability to obtain the best possible network rates.

Thus, the use of agile, software-defined radio nodes can provide a superior ability to

manage, upgrade and provision new services. The advantages of establishing an open,

modular, common service deployment platform include: broad acceptance of the

technology, and potential standardisation, resulting in lower development and acquisition

costs. In addition, this technology can help reduce stranded assets by supporting legacy

radio/sensor interfaces, while “future-proofing” deployments and reducing operational

costs by enabling software download of new radio functionality, and enhanced services.

Potential Consumer Benefits

The potential impact of project to the electricity consumer is indirect, and projected to be

along multiple dimensions. The consumer will have the freedom to purchase new home

electronic gadgets and have the comfort of knowing that they can work with key parts of

the installed infrastructure. In addition, we anticipate that the consumer will significantly

benefit from the energy information services and related services that are enabled, and that

these will in turn engender improved energy efficiency and demand responsiveness. Based

on initial estimations and empirical observations in related investigations at the University

of California at Berkeley, the DR based energy efficiency mechanisms that will be deployed

in this context can yield a potential savings ranging from 5 per cent to 30-49 per cent

depending on energy consumption and conservation patterns and weather patterns.

Benefit to the California electric market

It has been established that the California electric consumption patterns are such that there

can be as much as a 50% spike in peak demand during the (relatively few) very hot days

during summer. This translates into a spike in demand from a nominal load in the 30

90

Gigawatt range to peak loads in the range of 45 Gigawatts. m Enablement of demand

response capability will significantly assist in the reduction in capital and operating

expenditure that is incurred by addressing the energy problem on the supply side to

provide for peak capacity. It is also projected to dramatically improve the reliability of the

grid.

In view of these figures, observations and empirical evidence, we believe that the combined

deployment of Demand response technology, energy efficiency, and energy information

services that this project is intended to enable, will have a compounding benefit—in

economic as well as environmental terms—both to the end consumer at home and in the

enterprise, as well as to California.

General Benefits

The adaptability and future proofing of resulting systems will provide benefits for all of the

stakeholders in the energy ecosystem: state policy making and regulatory agencies such as

the California Energy Commission and Public Utilities Commission can legislate and

implement policies designed to mitigate peak power requirements on the energy grid

(thereby reducing capital expenditure for new power plants and ongoing operational

expenditure associated with operating these plants); utilities and Independent System

Operators will benefit by having technology that enables them to comply with regulatory

requirements, support dynamic real time pricing and emergency curtailment signals,

improve grid reliability, and bolster their existing business cases for advanced metering

infrastructure; equipment vendors will benefit from a set of reusable platform components

that can enable cost-effective products for their customers; and end consumers will benefit

from reduced energy consumption (and therefore reduced energy bills) while maintaining

desired comfort levels.

m These figures were obtained from conversations with the California Energy Commission, Commissioner Art

Rosenfeld, Ron Hofmann, and other consultants and authors; they are also documented in parts in various

publications from the DRRC.

91

Glossary

AAA Authentication, Authorization, and Accounting

A/D Analog to Digital

AES Advanced Encryption Standard

AMI Advanced Metering Infrastructure

AMR Automatic Meter Reading

ANSI America National Standards Institute

BPL Broadband over powerline

CATV Cable TV

CCMP Counter-Mode/CBC-MAC Protocol

CDMA Code Division Multiple Access

CDPD Cellular Digital Packet Data

CEC California Energy Commission

CFAA Computer Fraud and Abuse Act

CIEE

UCOP

California Institute for Energy and Environment, Office of the President,

University of California

CPUC California Public Utilities Commission

DR Demand Response

DSL Digital Subscriber Line

ECPA Electronic Communications Privacy Act

EM Electromechanical

EPRI Electric Power Research Institute

ESP Energy Service Provider

92

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

HVAC Heating, Ventilation, and Air Conditioning

iDEN Integrated Digital Enhanced Network

IECSA Integrated Energy and Communications Systems Architecture

IEEE Institute of Electrical and Electronics Engineers

IPSec IPSec is a framework of open standards developed by the Internet Engineering

Task Force (IETF). IPSec provides security for transmission of sensitive

information over unprotected networks such as the Internet.

ISO International Organization for Standardization

ISOs Independent Service Operators

LAN Local-Area Network

LEO Low Earth Orbit

MAC Message Authentication Code (Also used as an abbreviation for Medium Access

Protocol in the context of networking.)

NG Next Generation

NIST National Institute of Standards and Technology

NOC Network Operating Center

PG&E Pacific Gas & Electric

PON Passive Optical Networks

SCE Southern California Edison

SDG&E San Diego Gas & Electric

SDR Software Defined Radio

SPP Statewide Pricing Pilot

U.C. University of California

93

VPN Virtual Private Network

WEP Wired Equivalent Protection

WiFi Wireless Fidelity, IEEE 802.11 standard

WLAN wireless local area network

94

6.0 References

[Abichar 2005] Z. Abichar, Yanlin Peng, and J.M. Chang. WiMax: The Emergence of

Wireless Broadband. IT Professional, 8(4):44 – 48, July 2005

[Arens-Wright] Ed Arens, Paul Wright, et al. New Thermostat and Meter DRETD Project,

UC Berkeley, 2004.

[Bellare et al 98] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway. .Relations Among

Notions of Security for Public-Key Encryption Schemes. In Proceedings of CRYPTO '98.

[Blass & Zitterbart 2005] E.-O. Blass and M. Zitterbart. .Efficient Implementation of Elliptic

Curve Cryptography for Wireless Sensor Networks. Technischer Bericht, Telematics

Technical Reports TM-2005-1, Mar 2005 (ISSN 1613-849X).

[BORPH]

[So 2007] Hayden Kwok-Hay So, BORPH: An Operating System for FPGA-Based

Reconfigurable Computers, Ph.D. Thesis, University of California, Berkeley, 2007.

[Camera et al 2005] K. Camera, H. K.-H. So, R. W. Brodersen, "An Integrated Debugging

Environment for Reprogrammble Hardware Systems," Sixth International Symposium

on Automated and Analysis-Driven Debugging, Monterey, CA., September 19-21, 2005

[Cabric et al 2006] D. Cabric, A. Tkachenko, R.W. Brodersen, “Spectrum Sensing

Measurements of Pilot, Energy, and Collaborative Detection”, IEEE Military

Communications Conference (MILCOM), Oct. 2006

[CommonCriteria] Common Criteria,

http://www.commoncriteriaportal.org/public/files/ccintroduction.pdf.

[Chan et al 2004] H. Chan, A. Perrig, and D. Song. .Key distribution techniques for sensor

networks. In Wireless sensor networks, 2004, pp. 277.303. Kluwer Academic Publishers,

Norwell, MA, USA.

[Chang 2005]Chen Chang, "Design and Applications of a Reconfigurable Computing

System for High Performance Digital Signal Processing," Ph.D. Thesis, Advisor:

Robert Brodersen, University of California, Berkeley, 2005

[DRETD] Demand Response Enabling Technology Development Project,

http://ciee.ucop.edu/dretd/

95

[CR]

[FCC NPRM 2003] FCC, Notice of Proposed Rule Making and Order, ET Docket No. 03-322,

Dec 30, 2003

[FCC SPTF 2002] FCC Spectrum Policy Task Force, “Report of the Spectrum Efficiency

Working Group,” November 15, 2002

[FIPS] Federal Information Processing Standard (FIPS) 197: Advanced Encryption

Standard. (See also http://csrc.nist.gov/cryptval/140-2.htm)

[Goldwasser and Micali 84] S. Goldwasser and S. Micali. .Probabilistic Encryption. Journal

of Computer and System Sciences 28:270.299, April 1984.

[Hu & Perrig 2004] Y. Hu and A. Perrig. .A Survey of Secure Wireless Ad Hoc Routing.

IEEE Security & Privacy, special issue on Making Wireless Work, 2(3):28-39, IEEE,

May/June 2004.

[Hu et al 2003] Y. Hu, A. Perrig, and D. Johnson. .Packet Leashes: A Defense against

Wormhole Attacks in Wireless Ad Hoc Networks. In Proceedings of the Twenty-Second

Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM

2003), vol. 3, pp. 1976-1986, IEEE, San Francisco, CA, April 2003.

[Hu et al 2003b] Y. Hu, A. Perrig, and D. Johnson. Rushing Attacks and Defense in Wireless

Ad Hoc Network Routing Protocols. Proceedings of the 2003 ACM Workshop on

Wireless Security (WiSe 2003), pp. 30-40, ACM, San Diego, CA, September 2003.

96

[Hughes 2003] Joe Hughes, The Integrated Energy and Communications Systems

Architecture (IECSA) Project, Electric Power Research Institute June 4, 2003,

http://ciee.ucop.edu/dretd/

[ICP] http: //www.epri-intelligrid.com/

intelligrid/docs/intelligrid_Consumer_Portal_Project_Plan_November_2004.pdf

[ICP-CPS] Intelligrid Consumer Portal FAQ_and_Survey, April 4, 2005. From http:

//www.epri-intelligrid.com/

[IECSA 2003] Integrated Energy and Communications Systems Architecture. Initial

Applications Scope and Stakeholder Identification, Task 1 Final Report, 2003.

[IEEE 802.11i] IEEE 802.11i Std 802.11i, July 2004

[IEEE 802.1X ] IEEE 802.1X-Rev Draft 10.0, June 2004

[IEEE 802.11i] IEEE Standard for Information technology- Telecommunications and

information exchange between systems- Local and metropolitan area networks- Specific

requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical

Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security

Enhancements. IEEE Std 802.11i- 2004, Vol., Iss., 2004 pp. 1.175.

[IEEE 802.15.4] IEEE standard for information technology - telecommunications and

information exchange between systems - local and metropolitan area networks specific

requirements part 15.4: wireless medium access control (MAC) and physical layer

(PHY) specifications for low-rate wireless personal area networks (LR-WPANs). IEEE

Std 802.15.4-2003, Vol., Iss., 2003 pp.1.670.

[ITU] http://www.itu.org

97

[Jo et al. 2005] Young-Min Jo et al. Development of a Compact Internal Antenna for Commercial

CDMA/GPS Folder Type Handsets, SkyCross Inc. Technical report, Jan. 2005.

[Johnson Controls] Johnson Controls. Wireless Temperature Sensing System. Lit. Code No.

LIT-1171100. Available at http://cgproducts.johnsoncontrols.com/metfipdf/1171100.pdf

[Karlof & Wagner 2003] C. Karlof and D. Wagner. .Secure Routing in Sensor Networks:

Attacks and Countermeasures. Ad Hoc Networks, vol 1, issues 2.3 (Special Issue on

Sensor Network Applications and Protocols), pp. 293-315, Elsevier, September 2003.

[Mathworks] http://www.mathworks.com

[Mishra 06] S.M. Mishra, A. Sahai, and R.W. Brodersen. Cooperative Sensing Among

Cognitive Radios. In Proc. of the IEEE International Conference on Communications

(ICC), 2006

[Mishra et al 2006] S.M. Mishra, R. Tandra, A. Sahai, “The case for Multiband Sensing”,

Proc. Of the 45th Annual Allerton Conference on Communication, Control, and

Computing.

[Mitola 2001] Joseph Mitola III, “Cognitive Radio for Flexible Mobile Multimedia

Communications,” Mobile Networks and Applications, Volume 6, Number 5, Sept. 2001

[Network Management RON] Demand Response Enabling Technology Development

Project: Network Management Research Opportunity Notice, June 4, 2003,

http://ciee.ucop.edu/dretd/

[Neuman & Ts'o 1994] B.C. Neuman and T. Ts'o. .Kerberos: An Authentication Service for

Computer Networks. In IEEE Communications, 32(9):33-38. September 1994.

[Newsome et al. 2004] J. Newsome, E. Shi, D. Song and A. Perrig. .The Sybil Attack in

Sensor Networks: Analysis and Defenses. In Proc, of IPSN 2004, Berkeley, CA, April

2004.

[NSA] http://www.nsa.gov/

[OpenAMI] Advanced Metering Infrastructure. http://www.OpenAMI.org

98

[Parno et al 2005] B. Parno, A. Perrig and V. Gligor. .Distributed Detection of Node

Replication Attacks in Sensor Networks. In Proceedings of the 2005 IEEE Symposium

on Security and Privacy, May 2005.

[PCAST CIP 1998] PCAST Letter on Critical Infrastructure Protection, President’s

Committee of Advisors on Science and Technology, 10 December 1998,

http://www.ostp.gov/html/pcastcip.html A National R&D Institute for Information Infrastructure

Protection (I3P), Institute for Defense Analyses, April 2000, IDA Paper P-3511 White Paper

on the Institute for Information Infrastructure Protection, Office of Science and Technology

Policy, 11 July 2000

[Poon, Brodersen & Tse 2003]. Ada S. Y. Poon, Robert W. Brodersen and David N. C. Tse,

“Degrees of Freedom in Spatial Channels: A Signal Space Approach”, submitted to

IEEE Trans. on Information Theory, August 2003.

[Sahai 06] A. Sahai, R. Tandra, S.M. Mishra, and N.K.Hoven. Fundamental Design

Tradeoffs in Cognitive Radio Systems. In Proc. of the First International Workshop on

Technology and Policy for Accessing Spectrum, (TAPAS), 2006.

[Sastry & Wagner 2004] N. Sastry and D. Wagner. Security Considerations for IEEE 802.15.4

Networks. ACM Workshop on Wireless Security (WiSE 2004). October 1, 2004.

[Semantic Web] The W3C Semantic Web, http://www.w3.org/.

[SDR Forum] Software Defined Radio Forum, http://www.sdrforum.org

[So 2007] Hayden Kwok-Hay So, BORPH: An Operating System for FPGA-Based

Reconfigurable Computers, Ph.D. Thesis, University of California, Berkeley, 2007.

[Trs Systems] Trs Systems Inc. WT1630A, B, C WirelessWall Temperature Sensors., Rev. 6.

Available at http://www.trssys.com/specifications/WT1630%20rev6.PDF

99

[TCG] Trusted Computing Group, https://www.trustedcomputinggroup.org.

[Tandra 05] R. Tandra and A. Sahai. Fundamental limits on detection in low SNR under

noise uncertainty. In Proc. of the WirelessCom 05 Symposium on Signal Processing, 2005.

[Tkachenko et al 2006a] A. Tkachenko, D. Cabric, R.W. Brodersen, "Cyclostationary Feature

Detector Experiments Using Reconfigurable BEE2," International Conference on Dynamic

Spectrum Access Networks, April 2007.

[Tkachenko et al 2006b] Artem Tkachenko, Danijela Cabric, R.W. Brodersen, “Cognitive

Radio Experiments using Reconfigurable BEE2” Asilomar Conference on Signals, Systems, and

Computers, November 2006

[Wagner 2004] D. Wagner. Resilient Aggregation in Sensor Networks. 2004 ACM

Workshop on Security of Ad Hoc and Sensor Networks (SASN '04), October 25, 2004.

[Wander et al 2005] A. Wander, N. Gura, H. Eberle, V. Gupta, S. Shantz. Energy Analysis of

Public-Key Cryptography for Wireless Sensor Networks. In Third IEEE International

Conference on Pervasive Computing and Communication (PerCom 2005)., March 2005.

[WiMedia Specs] Javier del Prado Pavn, Sai Shankar N, Vasanth Gaddam, Kiran Challapali,

and Chun-Ting Chou. The MBOA-WiMedia specification for ultra wideband distributed

networks. IEEE Communications Magazine, 44(6):128 – 134, June 2006

[Xilinx] http://www.xilinx.com

[Zhang and Zheng 1997] X.M. Zhang and Y. Zheng. Cryptographically resilient functions. In

IEEE Transactions on Information Theory, 43(5):1740--1747, September 1997.

100

B-1

7.0 APPENDIX

7.1. A review of some OSI-related networking terms

For completeness, this Appendix briefly reviews the seven-layer Open System

Interconnection (OSI) reference model.

The Open System Interconnection (OSI) reference model describes how information from a

software application in one computer moves through a network medium to a software

application in another computer. The OSI reference model is a conceptual model composed

of seven layers, each specifying particular network functions. The model was developed by

the International Organization for Standardization (ISO) in 1984; it is often used as a

primary architectural model for intercomputer communications, although there are

normally some variations with the TCP/IP stack that had a parallel and earlier history of

evolution in the US and ARPANET. The OSI model divides the tasks involved with moving

information between networked computers into seven smaller, more manageable task

groups. A task or group of tasks is then assigned to each of the seven OSI layers. Each layer

is reasonably self-contained so that the tasks assigned to each layer can be implemented

independently. This enables the solutions offered by one layer to be updated without

adversely affecting the other layers.

Figure 35. The Layers of the OSI Model

The following list details the seven layers of the Open System Interconnection (OSI)

reference model:

101

B-2

� Layer 7—Application Layer

This layer supports application and end-user processes. Communication

partners are identified, quality of service is identified, user authentication and

privacy are considered, and any constraints on data syntax are identified.

Everything at this layer is application-specific. This layer provides application

services for file transfers, e-mail, and other network software services. Telnet

and FTP are applications that exist entirely in the application level.

� Layer 6—Presentation Layer

This layer provides independence from differences in data representation (e.g.,

encryption) by translating from application to network format, and vice versa.

The presentation layer works to transform data into the form that the

application layer can accept. This layer formats and encrypts data to be sent

across a network, providing freedom from compatibility problems. It is

sometimes called the syntax layer.

� Layer 5—Session Layer

This layer establishes, manages and terminates connections between

applications. The session layer sets up, coordinates, and terminates

conversations, exchanges, and dialogues between the applications at each end. It

deals with session and connection coordination.

� Layer 4—Transport

This layer provides transparent transfer of data between end systems, or hosts,

and is responsible for end-to-end error recovery and flow control. It ensures

complete data transfer.

� Layer 3—Network

This layer provides switching and routing technologies, creating logical paths,

known as virtual circuits, for transmitting data from node to node. Routing and

forwarding are functions of this layer, as well as addressing, internetworking,

error handling, congestion control and packet sequencing.

� Layer 2—Data link

102

B-3

At this layer, data packets are encoded and decoded into bits. It furnishes

transmission protocol knowledge and management and handles errors in the

physical layer, flow control and frame synchronization. The data link layer is

divided into two sublayers: The Media Access Control (MAC) layer and the

Logical Link Control (LLC) layer. The MAC sublayer controls how a computer

on the network gains access to the data and permission to transmit it. The LLC

layer controls frame synchronization, flow control and error checking.

� Layer 1—Physical

This layer conveys a logical bit stream over a physical medium -- e.g., electrical

signal (over a wire), light (over an optical fiber) or radio signal (for wireless

transmission) -- through the network at the electrical and mechanical level.

The physical layer defines the electrical, mechanical, procedural, and functional

specifications for activating, maintaining, and deactivating the physical link

between communicating network systems. Physical layer specifications define

characteristics such as voltage levels, timing of voltage changes, physical data

rates, maximum transmission distances, and physical connectors.

The seven layers of the OSI reference model can be divided into two categories: upper

layers and lower layers.

The upper layers of the OSI model deal with application issues and generally are

implemented in software. The highest layer, the application layer, is closest to the end user.

Both users and application layer processes interact with software applications that contain

a communications component. The term upper layer is sometimes used to refer to any layer

above another layer in the OSI model.

The lower layers of the OSI model handle data transport issues. The physical layer and the

data link layer are implemented in hardware and software. The lowest layer, the physical

layer, is closest to the physical network medium (the network cabling, for example) and is

responsible for actually placing information on the medium.

103

B-4

7.2. IPv6 or IPng (IP Next generation)

IPv6 is short for "Internet Protocol Version 6". IPv6 is the "next generation" protocol designed by the IETF

(The Internet Engineering Task Force) to replace the current version Internet Protocol, IP Version 4

("IPv4"). The IP v6 specifications are in RFC 2460.

Most of today's Internet uses IPv4, which is now over twenty years old. IPv4 has been remarkably resilient

in spite of its age, but it is beginning to have problems. Most importantly, there is a growing shortage of

IPv4 addresses, which are needed by all new machines added to the Internet.

IPv6 fixes a number of problems in IPv4, such as the limited number of available IPv4 addresses. It also

adds many improvements to IPv4 in areas such as routing and network auto configuration. IPv6 is

expected to gradually replace IPv4, with the two coexisting for a number of years during a transition

period.

The figures below show the packet structure, and the differences between IPv4 and IPv6.

104

B-5

Figure 36. IPv4 vs IPv6 Comparison

Streamlined

� Fragmentation fields moved out of base header

� IP options moved out of base header

� Header checksum eliminated

� Header length field eliminated

105

B-6

� Length field excludes IPv6 header

� Alignment changed from 32 to 64 bits

Revised

� Time to live � hop limit

� Protocol � next header

� Precedence and TOS � traffic class

� Addresses increased 32 bits � 128 bits

Extended

• Flow label field added

Figure 37. IPv6 Header Options

106

B-7

Figure 38 IPv6 Packet Format

107

B-8

7.3. XML

The Extensible Markup Language (XML) is a general-purpose markup language; more precisely, XML is a

general-purpose specification for creating custom markup languages. It is classified as an extensible

language because it allows its users to define their own “tags”. Its primary purpose is to facilitate the

sharing of data across different information systems, particularly via the Internet [Bray et al 2006].

It is a simplified subset of the Standard Generalized Markup Language (SGML), and is designed to be

relatively human-legible. By adding semantic constraints, application languages can be implemented in

XML.

[Bray et al 2006] Bray, Tim; Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau (September

2006). Extensible Markup Language (XML) 1.0 (Fourth Edition) - Origin and Goals.

7.4. SOAP

SOAP originally stood for Simple Object Access Protocol, and was also later used as an abbreviation for

Service Oriented Architecture Protocol, but is now simply SOAP. SOAP is a protocol for exchanging

XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation

layer of the Web services stack, providing a basic messaging framework that more abstract layers can build

on.

There are several different types of messaging patterns in SOAP, but by far the most common is the

Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to

another node (the server), and the server immediately sends a response message to the client.

7.5. REST

Representational State Transfer (REST) is a style of software architecture for distributed hypermedia

systems such as the World Wide Web. The term was introduced in the doctoral dissertation in 2000 by Roy

Fielding, one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification, and has

come into widespread use in the networking community. REST strictly refers to a collection of network

architecture principles that outline how resources are defined and addressed. The term is often used in a

looser sense to describe any simple interface that transmits domain-specific data over HTTP without an

additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can

conflict as well as overlap. It is possible to design any large software system in accordance with Fielding's

REST architectural style without using the HTTP protocol and without interacting with the world wide

web. It is also possible to design simple XML+HTTP interfaces that do not conform to REST principles, and

instead follow a Remote Procedure Call model.

108

B-9

7.6. Details of the RF Front End Design

In this section, we include some of the design details pertaining to the Agile radio testbed design that are

not elaborated upon in the main body of the report.

7.6.1. Front End Analog Hardware

The protocols that are currently being considered in context of Demand-Response and Home Area

Networks include WiFi and ZigBee, which lie in the 2.4 GHz and 900 MHz ISM bands. As a

consequence, we selected the following frequency bands for an initial experiment in the design of

the RF Front end analog hardware.

� 2.45GHz band: 2.2GHz – 2.7GHz Receiver

� 2.45GHz band: 2.2GHz – 2.7GHz Transmitter

� TV + ISM band: 600MHz - 1GHz Receiver

� TV + ISM band: 600MHz - 1GHz Transmitter

This choice has the benefit of including the bands of interest for DR/HAN contexts, while also allowing

bands that overlap with Analog TV and WiMAX.

2.45GHz +/- 250MHz Receiver Design

The salient aspects of this design are described below.

� The signal is split into I and Q digitally in the iBOB or BEE2. This can thus be described as “Real

sampling” design.

� The receiver operates in the 2200MHz – 2700Mhz range, and has a 500MHz bandwidth

� The input is down-converted to baseband, and digitized at 1.6 Gsps (Giga Samples per second) by

iADC

� 1.2 GHz processing thru iDAC, upconverted to center frequency fc = 2.45GHz

� Existing Simulink and Verilog libraries are used to implement the hardware on iBOB or BEE2

� Digital signals received into or transmitted from Block RAMs on BEE2. Digital signals in Block

RAMs ready for processing.

109

B-10

2.45GHz +/-250MHz Receiver

BEE2

Existing

Board

Gain

VLFX-500

DC-500MHz

ZX05-30W

300MHz-4GHz

Mixer

Band Pass Filter

Frequency

Synthesizer

Frequency

synthesizer

Analog Devices EVAL-ADF4106EBZ1

withV600ME05 (VCO 1500-2350MHz)

800MHz

(1.6Gsps data rate)

Note:All part nos: Minicircuits unless otherwise indicated

High

Pass

Filter

Low

Pass

Filter

iADC

Existing

Board

Atmel

AT84AD001

iBOB

Existing

Board

Xilinx

XC2VP50

Low

Pass

Filter

VHF-1910+

2200-4400MHz

fco 1910MHz

SLP-2950

DC-2700MHz

fco 2950MHz

+12v

GND

Analog Devices EVAL-ADF4106EBZ1

withV585ME40-L (VCO 800-1650MHz)

+9v (battery) +9v (battery)

SHM031707

ZX60-3018G

20-3000MHz

20dB gain

Gain

+12v

GND

2.2GHz GND

+5v

Figure 39 2.45GHz +/- 250MHz Receiver Design Block Diagram

Figure 40 2.45GHz +/- 250MHz Receiver Design using minicircuits

110

B-11

2.45GHz +/-250MHz Receiverwith iADC and iBOB

Figure 41 Receiver with iBOB and iADC

SDR Frontend

2.4GHz +/-300MHz Receiver v1.0

SDR Frontend

2.4GHz +/-300MHz Receiver v1.0

Band-

pass

ADC

Existing

Board

IBOB

Existing

Board

BEEII

Existing

Board

GainOptional

gain

Splitter

0 degree

MixerLow Pass Filter

VLF-225

ZX05-30W

Mixer

Mitek AFD3-02302708

ZX60-3018GZX10-2-42

Splitter

90 degree

Frequency

Synthesizer

Frequency

synthesizer

Analog Devices EVAL-ADF4360-1EB1

Or

Valon Technology

2400MHz +10dBm

800MHz

0dBm

Notes:

All part nos: Minicircuits

unless otherwise indicated

ZX10Q-2-27

Figure 42 Broadband receiver design at 2.4 GHz

111

B-12

SDR Frontend

2.4GHz +/-300MHz Transmitter v1.0April 28, 2006

SDR Frontend

2.4GHz +/-300MHz Transmitter v1.0April 28, 2006

DAC

Existing

Board

IBOB

Existing

Board

BEEII

Existing

Board

Splitter

0 degree

MixerLow Pass Filter

VLF-225

ZX05-30W

Mixer

Mitek AFD3-02302708

ZX60-3018GZX10-2-42

Splitter

90 degree

Frequency

Synthesizer

Frequency

synthesizer

Analog Devices EVAL-ADF4360-1EB1

Or

Valon Technology

2400MHz +10dBm

800MHz

0dBm

Notes:

All part nos: Minicircuits

unless otherwise indicated

ZX10Q-2-27

Bandpass Gain Optional

Gain

Figure 43 Broadband Transmitter Design at 2.4 GHz

The illustrations above indicate the SDR broadband front designs that have been coupled into the system.

Front End Matlab Designs

For both the receiver and transmitter designs, the blocks used were assembled from the Simulink Xilinx

System generator library, custom BEE2 library blocksets, and software programmable registers.

The transmitter design shown in the figure depicts the signal flow path from the Optical Transceiver via

the XAUI ports to the IBOB, and then onto the IBOB � DAC� analog out.

112

B-13

Figure 44 The transmitter design – Optical Transceiver -> XAUI -> IBOB -> DAC-> analog out

The Receiver Design – Analog signal flows from the RF analog frontend -> ADC -> IBOB-> Xaui connector

to optical transceiver. The ADC, IBOB, and XAUI connector all have different clock rates. The signal

needed to be controlled thru each step.

113

B-14

Figure 45 Fragments of the Transceiver design

114

B-15

Figure 46 The Receiver Design. Analog Signal path from RF Analog Front end to ADC, IBOB, Xaui connector to

the Optical tranceiver

7.7. Cognitive techniques for Interference avoidance

This section of the Appendix contains details relating to the implementation of Detection and Avoidance techniques in

the context of our Cognitive radio research (but that were not included in the main body of the report).

7.7.1. Abstract

Cognitive radios have been advanced as a technology for the opportunistic use of under-utilized spectrum

wherein secondary devices sense the presence of the primary user and use the spectrum only if it is

deemed empty. The distinguishing aspect of cognitive radios is the ability to sense the primary user and

modify their transmission parameters to avoid interference to the primary.

In this section we explore the use of cognitive technology to enable the operation of ultra-wideband (UWB)

devices in WiMax bands. In this particular example UWB devices must incorporate cognitive technology to

detect and avoid (DAA) WiMax devices in certain regulatory domains.

115

B-16

We start by discussing various options for detection and avoidance. We then describe the obstacles faced in

achieving robust detection and avoidance with an on-chip implementation of basic DAA functionality.

This implementation is based on the energy detector and can reliably detect WiMax uplink transmissions.

Finally, we describe an empirical set up for the operation of a single cognitive technology enabled UWB

device with a WiMax system. This interaction also highlights the problem of dealing with listen before

speak primaries where secondary transmission could interfere by denying the primary access to the

medium.

7.7.2. Introduction

Ultra-wideband (UWB) technology is termed as such since it occupies large swathes of spectrum and uses

very low power to communicate. UWB’s intended use is in the 3- 10GHz bands for short range (~10m)

communications for implementing Wireless Personal Area Networks (WPAN) [WiMedia Specs]. WiMax

(Worldwide interoperability for Microwave access), on the other hand, is the commercialization of the

IEEE 802.16 standard and is meant to provide high speed wireless data services over a much wider area

(~5 miles) [Abichar et al 2005] . The target bands for WiMax deployment are the 2.4GHz, 3.5GHz and

5.8GHz bands. The 3.5GHz band is free in most countries except the United States. Operation of WiMax in

the 3.5GHz band is susceptible to interference from UWB devices operational in band group 1 (3.168GHz

to 4.752GHz) as per the WiMedia specifications [WiMedia Specs]. This is particularly true in Europe, Korea

and Japan as illustrated in Figure 31.

The usage models of WiMax and UWB are both centered around laptop cards and hence an UWB device

could potentially interfere with reception at the WiMax Customer Premise Equipment (CPE) (See Figure

32. Potentially disruptive interference between WiMax and UWB occurs when the WiMax equipped

Customer Premise Equipment (CPE) is in close proximity of an UWB communication pair. (See Figure 32).

However since the two services occupy different spatial scales, if the transmissions of UWB are properly

coordinated they could complement each other. The traditional regulatory mechanism to handle

interference is to separate contenders in space or in frequency. Thus regulators would impose artificial

limits on transmissions to minimize interference. This approach precludes dynamic spatial/temporal reuse

of the spectrum. Furthermore, with all frequency bands being allocated multiple times over, new spectrum

is not readily available for such allocation. Thus by declaring that all new users of the spectrum are

secondary users and requiring that they must detect and avoid (DAA) the primary user, the regulators are

opening up spectrum for opportunistic use. In the absence of DAA functionality, UWB devices would have

to forfeit the band designated as ‘DAA required’ in Figure 31 which would greatly reduce the spectrum

available for communication.

In this section, we first describe the detection problem, profiling both downlink and uplink detection. We

then explain various avoidance techniques and justify the adopted approach of using a ‘notch filter’.

Following this, we explain on-chip detection functionality as well as the various practical problems in

116

B-17

implementing robust detection. Finally, we describe research plans for investigating coexistence results

with an actual WiMax system.

Figure 47. Overlapped frequency allocation for WiMax and ultra-wideband (UWB)

117

B-18

Figure 48. Potentially disruptive interference between WiMax and UWB occurs when the WiMax equipped

Customer Premise Equipment (CPE) is in close proximity of an UWB communication pair.

7.7.3. Detection

The detection problem for UWB can be formulated as a binary hypothesis testing problem, where the aim

is to distinguish between the ‘signal present’ hypotheses and the ‘signal absent’ hypotheses.

When the ‘signal present’ hypotheses is true, the WiMax signal is present together with noise. The WiMax

signal could be a downlink transmission from the basestation to the CPE or uplink transmission from CPE

to the base station or could include both if WiMax employs time division duplexing between uplink and

downlink transmissions.

The key parameters in evaluating a detection algorithm are the probability of missed detection (PMD) and

the probability of false alarm (PFA). Probability of missed detection is the probability that the detection

algorithm is unable to detect the presence of a primary signal. Probability of false alarm on the other hand,

is the probability that noise triggered the detection algorithm into falsely believing the presence of a

primary signal. We would like to minimize both.

7.7.4. Downlink Detection

The downlink detection problem is similar to the digital TV detection problem being studied by the IEEE

802.22 group and other research efforts. In the presence of a WiMax basestation, the downlink will be

present with a very high activity factor which enables faster detection. However, if the UWB device is far

from the base station, detection of the downlink signal requires high detection sensitivity (Detection

sensitivity is defined as the minimum received power per unit bandwidth (dBm/MHz) that can be detected

while achieving the target PMD) which can be achieved only with large sensing times For a given target PMD,

the detection sensitivity of the receiver can be calculated based on the distribution function of the loss (path

118

B-19

loss, multipath, shadowing [Mishra 06]. An easier way to calculate downlink detection sensitivity

requirements, would be to set the sensitivity equal to that of a typical WiMax receiver ($\sim$-

100dBm/MHz) and budget an additional 10-20dB fading margin. Cooperative sensing can help reduce the

fading margin to this level [Mishra 06].

7.7.5. Uplink Detection

Detecting the uplink is relatively easier since the subscriber station is close to the UWB device. If the

downlink and uplink transmissions are time multiplexed, calculating the sensitivity is straight-forward. In

this case, channel reciprocity holds and the detection and interference ranges are tightly coupled (This

assumes no spatial selectivity). The thermal noise floor in a 1MHz band is -114dBm. Typical Interference-

to-Noise Ratio (INR) requirements at a WiMax receiver is around 6dB. Assuming a receiver noise figure of

5dB, this gives us a maximum interference limit of -115dBm. Since the UWB transmission device has a FCC

imposed power limit of -41dBm/MHz, a 74dB (-41-(-115) = 74) isolation is needed between the WiMax CPE

and UWB devices. Typical WiMax CPE's transmit at 21dBm in a 20MHz band (~8dBm per MHz). With a

74dB isolation, this translates into a detection sensitivity of -66dBm/MHz.

In the case where the uplink and the downlink are separated in frequency, the multipath characteristics of

the two may be completely different. On the other hand, shadowing correlation between downlink and

uplink frequencies is fairly high (0.66-0.9). Together we can budget an additional 20 dB for multipath and

shadowing mismatch. Hence in this case we will need to detect a signal of -86dBm/MHz.

As opposed to downlink detection, uplink detection confirms the presence of an actual WiMax CPE.

Unfortunately, a CPE may never transmit if it cannot hear the downlink in the first place. Hence

mechanisms are needed in the UWB device to ensure that the downlink signal can be heard by the CPE.

The problem that the CPE may never transmit if it does not hear the downlink, falls under the general

problem of dealing with primary devices which follow the listen before talk protocol. Interference to the

primary in this case is different from the traditional additive interference; a secondary does not interfere

with a primary's transmission but with its access to the medium. Another case of the same would be

cognitive radios operating in the ISM bands where WiFi radios are the de facto primary users. Since WiFi

radios employ Carrier Sense Multiple Access (CSMA) protocol, they will not transmit if they hear another

secondary device and hence may never access the medium.

7.7.6. Avoidance

The avoidance problem requires a UWB device to cease transmission and/or reduce transmit power in the

bands where a WiMax link is detected. Avoidance techniques fall under one of the two classes - Receiver

Aware or Receiver Unaware. In the first class of techniques, the receiver is aware of the changes in the

transmission parameters (e.g. the receiver knows which subcarriers are not used) and may use the

knowledge to improve its link performance. In the second class, the receiver is unaware of the

modifications and tries to reconstruct information lost by exploiting the redundancy due to channel

119

B-20

coding. The following is a list of possible avoidance techniques specific to the UWB implementation based

on the WiMedia standard (WiMedia specifies OFDM modulation using a 128-point FFT):

Band Dropping: Each band group (a band group consists of three 528MHz wide frequency bands) is

utilized for UWB communication by hopping between the three bands. If WiMax is detected on any one of

the bands, the UWB devices could switch to a two-band hopping sequence. The switching is directed by

the MAC layer at both the transmitter and receiver.

Subcarrier Nulling: In this approach, the transmitter does not send data on subcarriers that need to be

avoided. The receiver may or may not know about the existence of the nulled subcarriers. The effect of

subcarrier nulling on the UWB spectrum is shown in Figure 3. Even with 48 subcarriers nulled, the

maximum attenuation possible is 22dB, due to the sidelobes of the neighboring subcarriers (those close to

the nulled subcarriers) filling up the `notch'.

Windowing: The problem with subcarrier nulling is that the sidelobes of the sinc impulse (due to the

rectangular window, each subcarrier is convolved with a sinc impulse in the frequency domain) are not

attenuated enough. One way around this problem is to smoothen the time domain waveform by using a

raised cosine filter. The receiver does not need to be aware of the windowing function being used. Our

simulations reveal that a combination of subcarrier nulling and a raised cosine window, can yield a

maximum attenuation of 25dB (this is true even with raised cosine roll-off factor (β) equal to 1).

Unfortunately, using the raised cosine filter violates the WiMedia specifications which require a null

postfix.

Cancellation Carriers: Another way to combat the problem is to use a few subcarriers adjacent to the

subcarriers being avoided to suppress the sidelobes of the transmitted spectrum. This technique is

sometimes referred to as `active interference cancelation'. The information on the subcarriers that have

been `spoiled' can be recovered by channel decoding. A system of linear equations has to be solved to

compute the coefficients of the cancellation carriers which requires on-chip matrix inversion -- an area

intensive proposition. Cancellation carriers can achieve large attenuation levels.

Notch Filter: The transmitter implements a digital notch filter in the time domain (post IFFT) so as to notch

out the corresponding subcarriers. Again, the location of the notch may or may not be available to the

receiver. The digital notch filter overcomes the deficiency of subcarrier nulling by removing the sidelobes.

Attenuation of around 40dB at the DAC input can be achieved by using a notch filter of sufficient order.

However, the actual notch depth at the RF output, as with any of the nulling/notching techniques

described earlier, is limited by the precision of the DAC and the non-linearities/phase noise of the RF.

Figure 3(b) shows the actual spectrum of the UWB signal with a notch of width 13 subcarriers. The

attenuation achieved is greater than 27dB.

For the purposes of DAA, notch filtering was the avoidance method of choice since it did not violate the

WiMedia specifications and required minimal change to the hardware.

120

B-21

If the avoidance algorithm achieves a maximum of x dB reduction in transmitted power, then the UWB

device can transmit with reduced power as long as the detected uplink signal is less then -86+x dBm/MHz.

With a well calibrated sensing device, such an estimate of the power of the detected signal is reasonable to

expect if the received signal is above the detection sensitivity.

121

B-22

Fig. 3 (a) UWB spectrum with multiple subcarriers nulled. Attenuation from subcarrier nulling is limited to 20-

22dB. (b) Actual UWB spectrum with a notch width of 13 subcarriers and a notch depth of 27dB. As opposed

to subcarrier nulling, a notch filter can achieve a depth greater than 27dB for all notch widths (5/13/21

subcarriers).

7.7.7. WiMax Detection: Design and Implementation

Traditionally, cognitive radios have been envisioned with separate sensing radios. UWB DAA functionality

on the other hand, needs to be implemented on-chip and sensing has to be interleaved with transmission

and reception. The reasons for this are the following:

• The silicon cost of implementing additional DAA functionality needs to be minimized. Many of the

modules of the traditional receiver (for e.g. the FFT in the OFDM-based WiMedia UWB system)

need to be reused.

• A separate sensing radio attempting to sense while UWB transmission is also on in the same band,

needs a mechanism to subtract the transmitted waveform from the sensor results. This is a difficult

task. Uncertainty about the power of noise and interference can limit the detection sensitivity

Energy Detection

In the case of the Energy Detector, we only make assumptions about the average power of the primary

signal. To facilitate analysis, we assume that the signal is a white Gaussian process with a variance equal to

the average power. The Gaussian assumption allows us to derive the sufficient statistics for this detection

problem which turns out to be the normalized power in the received signal. The decision rule then

compares the energy estimate of the observed sequence with a threshold (γ). We set the value of this

threshold to meet the required probability of detection (PD) and probability of false alarm (PFA). Since the

decision involves a comparison of the power of the signal with the power of noise, any uncertainty in the

power of noise can limit detector performance since we will need to budget for worse case scenarios. This

performance limitation due to noise uncertainty is discussed in [Tandra 05] where the authors show that

noise uncertainty can limit the minimum signal level that can be detected. Hence noise estimation is key to

ensuring that the target PMD and PFA are met.

The key guiding principles for the development of an energy detection algorithm were the following:

• Ensure that the target values of PMD and PFA are met over the entire 1.584 GHz spectrum range.

• Engineer the detection parameters to eliminate the case where a WiMax signal on a given frequency

was not detected while a false alarm was triggered on another frequency.

• Minimize implementation complexity while ensuring that the target detection sensitivity of -86

dBm/MHz.

Figure 4(a) shows the on-chip detection engine. The Analog-to-Digital converter samples the incoming

analog input at 528MHz. The Fast-Fourier-Transform (FFT) transforms the complex output into frequency-

122

B-23

domain, with 128 frequency bins, each 4.125MHz wide. The PSD Estimate Engine integrates the energy in

each bin over a specified integration period. The maximum integration period is 20µs which is much

smaller than the length of a typical WiMax packet (2ms-20ms). In the transmit direction the data is

converted into a time-domain waveform by the Inverse Fourier Transform (IFFT) module. This waveform

is run through a notch filter which takes out those frequency components where WiMax services have been

detected.

Figure 4(b) shows the spectrum capture for a -80dBm sinusoidal signal via the on-chip energy detector. The

capture highlights some of the practical technical difficulties in implementing energy detection. These

issues are discussed in the following:

• Noise and Interference Estimation: As stated earlier, the biggest problem in energy detection is

adequate noise and interference estimation (especially from other secondaries). In [Sahai 06], it has

been suggested that guard bands around the primary be used for interference estimation. As long

as guard bands are within a coherence bandwidth of the primary spectrum, interference estimation

within the guard bands will be highly correlated to the interference in the primary band. [Sahai 06]

also requires that the interference estimation bands be more than a Doppler shift away from

primary signal. In the case of WiMax, where primary is static, the Doppler shift should be zero. For

our implementation, if we suspect that the primary signal is present on subcarriers n, … n+i, then

we use the remaining subcarriers 1 … n-1, n+i+1 … nmax as an estimate of the noise and interference

in the system. This causes the detection sensitivity to vary with time but keeps false alarm rate low.

• Dealing with Spurious Tones: Spurious tones as seen in Figure 4(b) on subcarriers 0 and 64 can

affect the noise estimation process (The spurious tone on subcarrier 0 is due to carrier leakage at the

mixer stage in the RF). The location of the spurious tones can be determined by calibration on

power-up. Hence we need to replace each bin suspected of spurious tones with an average of the

bins surrounding it. As opposed to ignoring the bins, this averaging allows the detection of WiMax

signals even within the subcarriers housing spurious tones.

• Detecting narrowband signals - the need for averaging: Some WiMax deployments can be at

bandwidths as small as 1.25MHz. Such narrowband signals are hard to detect when they straddle

the boundary of two subcarriers. To allow the detection of such signals we need to average across

adjacent bins. Again, this lowers the detection capability in average but eliminates the case with

narrowband signals are missed.

• Dealing with the Baseband filter: In Figure 4(b) we see the effect on the baseband filter in shaping

the noise and the signal. The baseband filter shape has to be compensated for before the detection

process can start.

123

B-24

• Bin Size: Since the FFT size is fixed by the Wimedia standard, the noise bandwidth per bin is fixed

at 4.125MHz. This means that large bandwidth signals are easier to detect than sinusoidal signals.

• Automatic Gain Control (AGC): Figure 4(c) illustrates the transfer function for a tone at 3.3GHz.

Due to the presence of the baseband filter this transfer function is frequency specific. On the lower

left corner, the transfer function flattens since the gain is at a maximum. On the right top corner, the

flattening of the transfer function occurs since the AGC algorithm would not reduce the gain

beyond a certain value. So, for this implementation the linear range of operation (wherein we can

estimate the WiMax power) is limited to 25dB. This implies that even if our avoidance algorithm

could provide attenuation beyond 25dB we would be unable to use the additional attenuation since

our estimate of the WiMax power is not accurate beyond this point.

7.7.8. Practical Detection Algorithm and Results

The final detection algorithm took into account the factors listed above but had to compromise on

detection capability to reduce memory and run-time costs.

Here are some of the salient features of the algorithm implemented on the PowerPC of a Xilinx Virtex-II

Pro FPGA:

• Detection of each subcarrier occurs by using all other subcarriers as an estimate of noise. For the

actual implementation we used a single mean as a noise estimate for all tones. This sacrifices

detection sensitivity but leads to simpler code for the FPGA.

• We employ a two level detection scheme. In the first level, candidate subcarriers are selected.

Adjacent subcarriers are grouped together and these groups of subcarriers were treated as

candidate primary systems. At the second level, the candidate system with `significantly' larger

power than the others was selected as the primary system. Based on the bandwidth of the selected

primary, the appropriate notch width (5/13/21 subcarrier wide) was chosen.

• The threshold values for selecting candidate subcarriers and the final primary system were

optimized to achieve a PMD of 0.1.

Table I shows Matlab and experimental detection results for various WiMax bandwidths. The theoretically

calculated sensitivity for 64 symbols over a bin bandwidth of 4.125MHz is -110dBm [Sahai 06]. The device

has a noise figure of 6dB which implies that there is a further 14dB sensitivity loss due to baseband filter

compensation, conservative threshold setting, spurious tones and errors in noise/interference estimation.

Furthermore, there is a further loss of 3-4dB from moving the detection algorithm from floating point

implementation to fixed point implementation in C on the PowerPC.

124

B-25

7.7.8.1. Towards Coherent Detection

Energy detection suffers from noise uncertainty, spurious tones and filter compensation effects. To achieve

lower detection levels (especially to sense the downlink), we need to exploit features of the WiMax packet.

One such feature is the packet preamble. IEEE 802.16d specifies two kinds of preambles: the long and short

preamble. The long preamble consists of two WiMax OFDM symbols. In the first symbol every 4th

subcarrier is loaded with a PN sequence. In the time domain, this leads to replication which is easy to

identify with cross correlation. On correlating the received sequence with the known preamble, 4 peaks

separated by 64 symbols are clearly identifiable. Figure 5(a) shows the structure of the long and short

preambles while Figure 5(b) shows the 256 point auto-correlation of the long preamble with a cyclic prefix

of 16 symbols.

Figure 4(a) also shows the proposed architecture of the Coherent Detection Engine. The bandwidth and

center frequency detection engine programs the downsampler and filter blocks to downsample the

candidate primary signals and remove aliases. The on-chip memory is fast but limited. Down sampling the

signal reduces the number of samples that need to be stored. The downsampled signals are correlated in

the Correlation Engine with known patterns and the results are analyzed on the FPGA.

For now, we only use Matlab simulations to evaluate coherent detection sensitivity for given values of PMD

and PFA. Our simulations show that for PMD and PFA of 0.1 and 0.1 respectively, coherent PMD = 0.9 or 0.1

detection can detect signals as low as -120.5dBm/MHz.

125

B-26

Figure 4. (a) Detection Engine implemented on-chip. The DAA functionality is implemented on a UWB RF/digital

baseband chip fabricated in TSMC 0.13um process technology. The chip contains 2 RF/ADC receiver chains, operating at

1.2V and measures 18mm2 in silicon area. The DAA relevant area (FFT/Notch filter) is around 1mm2. (b) Spectrum

capture of a -81dBm tone (c) Energy Detection transfer function at 3.3 GHz

126

B-27

Figure 5: (a) WiMax (IEEE 802.16d) long and short preambles (b) 256 point autocorrelation of the long preamble (Cyclic

prefix length = 16 symbols) which amounts to a processing gain of 24dB

127

B-28

Table 1 Detection sensitivity for WiMax signals of various bandwidths and center frequencies

128