WO2014016729A1 - Sensing information service and its use in urban service planning system - Google Patents

Abstract

A method and corresponding system is disclosed that provides a sensing information service platform that builds on an existing communication infrastructure and protocols to exploit the capabilities of an underlying heterogeneous sensing infrastructure while hiding its inherent complexity from users and application developers. Also disclosed are applications related to collection and analysis of selected available data and based upon this data, users are provided information on the attractiveness of a certain geographical area for a specific urban development. An exemplary system architecture comprises an urban service planning engine (USPE) 610 and a sensing broker (SB) 310 which enables access to heterogeneous Wireless Sensor and Actuator Networks (WSANs) 230 and 240. Each WSAN may be remotely managed and controlled by a Central Management System (CMS) 210, 220. Devices in the WSANs can be reached through gateways 225, 235 or they can be reached directly through a network infrastructure (e.g., Internet). Service connections are established between users and the SB to identify, configure, and access sensing data. A WSAN preferably is an outdoor lighting network having a plurality of lighting units and sensors. The USPE defines attractiveness of geographical areas regarding planning decisions based on sensing information.

Description

Sensing Information Service and its Use in Urban Service Planning System

This application relates to the field of wireless sensor networks, to include Wireless Sensor and Actuator Networks (WSANs). More particularly, the application relates to a method and a system for utilizing such networks to create a heterogeneous infrastructure for obtaining sensed information that can be accessed in a user friendly manner. Further, this application relates to a method and a system whereby user devices (fixed or mobile) interact with an urban service planning engine (USPE) and such an underlying sensing infrastructure to obtain recommendations for use in urban planning.

Data collection and monitoring in an urban environment has a number of applications, from transportation, to industrial processes, to environment and healthcare. Wireless Sensor Networks (WSNs), to include Wireless Sensor and Actuator Networks (WSANs), currently exist and have been used for monitoring and control of physical systems in a number of applications, from transportation, to industrial processes, to environment and healthcare. Networked sensors embedded in the environment and infrastructure (e.g., in cars, roadway infrastructure, street lights, and buildings) will form a huge information infrastructure, also called Internet of Things (loT).

Existing communication technologies, network infrastructure and protocols have enabled remote data collection and processing from virtually any type of sensors deployed across large areas. By way of example, U.S. Pat. No. 7,020,707; entitled "Method for Collecting and Processing Data Using Internetworked Wireless Integrated Network Sensors (WINS)" issued to Gelven et. al on March 28, 2006 and hereby incorporated by reference; describes microsensor technology, low power signal processing, computation and wireless networking capabilities that enable deployment of embedded intelligent sensor and actuators systems in numerous applications.

In addition, mobile user devices have also become source of data, and large scale mobile sensing has emerged recently as a new field for innovation (see e.g., Lane et al "A Survey of Mobile Phone Sensing," IEEE Communication Magazine, September 2010: 140-150). Mobile sensing devices are ubiquitous platforms to collect human and environmental information on various scales, from a person's specific activities to community wide information. Similarly, sensing and communication capabilities in cars or other personal devices (watches, activity monitors, etc) open up new opportunities to collect information that are useful for optimization of many intelligent systems.

Recently, adding communication modules to outdoor lighting units to form outdoor lighting networks (OLNs) has opened up new opportunities to collect data on a large scale (e.g., city level). OLNs can provide many benefits including energy and maintenance savings through remote control and management of outdoor lighting. Light units are becoming more intelligent, and when combined with various sensor devices and communications capabilities, provide another platform to collect information, such as traffic, air quality, images and many other types of sensed data. An exemplary OLN system is described in co-pending patent application entitled "IMAGING SERVICE USING OUTDOOR LIGHTING NETWORKS" filed on September 22, 201 1 in the US Patent and Trademark Office and afforded serial number 61/537945, the contents of which are incorporated by reference, herein.

Typically, wireless sensors and actuators networks are deployed for a specific purpose, each with its own infrastructure to collect, process and present data to the target application and users. For instance, a city may maintain networks of traffic sensors, weather monitoring stations, outdoor lighting, power meters, surveillance cameras, etc. Each is usually a self-contained system including specific sensing technologies, communication protocols, and backend data storage/processing/visualization. There are solutions, mainly IT infrastructure and backend application frameworks, to integrate, visualize and process the data from multiple systems on a city management level (e.g. information management platforms from IBM, Cisco, Living PlanelT, ...). Similar concepts are also available for buildings (also called building management systems (BMS)).

In the future, the number of sensors, actuators and intelligent systems will increase and new usage models and applications should be enabled for the huge amount of data available besides integration, centralized access/visualization and data analytics-based system optimization enabled by existing technology. Addressing that need is one aspect of the present invention. By way of example, consider a city with several WSANs deployed to support intelligent systems (e.g. traffic management, surveillance, environment monitoring, lighting control, building automation, etc.). As previously described, information from such WSANs may be accessible through web-based platforms by city officials at different departments, government entities, or private businesses. Certain types of information may even be available to regular users/citizens through a web-service. For instance, users can subscribe to services that generate traffic alerts, news, weather, and many other types of notifications using RSS feeds, SMS, e-mail and social network services (e.g. Twitter, Facebook, etc). However the existing alert services are still specific to a particular subject, e.g. traffic, or weather, or news.

There is no abstract way for users to access different sensing information services without owning or even knowing the details of the underlying sensing infrastructure, which can vary significantly in dependence on the different forms of WSANs involved. That is, access to the huge amount of data and information that can be provided by WSANs is either limited to operators/users of each specific system (e.g. facility managers, traffic engineers, police department, ...) or at best processed by specific backend systems and used for data mining and optimization of the independent systems (e.g. traffic management, adaptive lighting control based on traffic and weather forecast, ...). Today's backend management systems cannot provide an easy way to access the underlying heterogeneous sensing capabilities.

For large scale situations, the entire sensing infrastructure typically will not be connected to a single/central backend system, such as a whole city information management system. Further, in such systems there are different WSANs with specific purpose sensing devices and proprietary protocols. Moreover, the sensing infrastructure may grow with time, new sensors and actuators may be deployed, others may become more accurate, and others may be replaced or disappear. The evolving WSANs that form the overall sensing infrastructure will likely be managed independently. The present invention enables accessing and providing such potentially valuable information to many applications and a broader range of users beyond what today's technology supports.

In the current state of the art there is no way for a regular user (e.g., a citizen) or application developer to make use of heterogeneous and evolving sensing infrastructure that might be available. Firstly, there is no simple and standard way to identify what sensing information is needed for a certain application/user. In other words, even if one could visualize and communicate with all sensors and actuators available in a city (e.g., as enabled by protocols proposed in Dawson-Haggerty et al, "sMAP - a Simple Measurement and Actuation Profile for Physical information," Sensys 2010, November 2010; hereby incorporated in its entirety by reference and hereinafter referenced as "the Dawson-Haggerty article"), it would be too complex to decide what data, what devices, where and at what time data is needed for a particular application. There is no solution to map the application/user information requirements to the sensing requirements including sensing devices, data types/format, and even more complex metadata such as space, time, granularity and precision associated with the data. The current invention provides a method to capture the high-level user's needs, (e.g., physical aspects, time, areas of interest, etc.) in a format that is easily understood by regular users. Then by identifying and storing the sensing capabilities available across heterogeneous WSANs (e.g. type of sensors available, accuracy, area, time availability, etc), it is possible to map the user needs to the closest available sensing capabilities. Secondly, after the sensing requirements are defined, there is no solution to obtain the relevant data for a certain application/user across heterogeneous WSANs.

U.S. Pat. No. 7,020,707 (discussed above) describes various ways for users to configure, control, collect and process data from wireless sensor nodes. For instance, the WINS gateways described therein provide remote users access to the sensing nodes (WINS node). However, this patent requires that the sensors and networks follow a common network architecture including sensors at the bottom layer, gateways (or data collectors/aggregator) at intermediate layers and central management systems (including data bases), which enable remote users to access/control/configure the system. That is, it does not describe how to leverage the heterogeneous sensing infrastructure to build applications, while hiding the complexity from users/developers.

The Dawson-Haggerty article does propose Web-based protocols that enable access to sensing information and actuators independent of proprietary implementation details of the devices. By way of example, users can access data and control a device by using an URL-encoded string: - a user could read the power measurement of a connected electrical meter through a web application using

http://companvA/data/ABC/meter/total power/reading. The article also describes an application that enables visualization and tracking of metadata associated to connected sensors including physical location, measured quantities, etc. The article thus provides flexibility to application developers, as they can use a standard (web-based) way to communicate with devices abstracting the specific device's implementation, and visualize potentially all available sensors and their corresponding properties. However, consider the situation in which a city has thousands or even millions of sensors deployed and connected to the Internet. An application developer could access/control any of the devices using the device's URL. This is certainly an advancement when compared to device and manufacturer's specific data format, and protocols. However, it does not provide an easy way for any regular person, or even skilled software

engineers, to identify what device(s) and data is relevant to a certain application and user's needs given the space, time and device diversity expected in smart buildings, cities and eventually the Internet of Things. In other words, the centralized access to a large number of sensors will be extremely complex to handle and effectively utilizing the available heterogeneous infrastructure to implement different applications would be a significant challenge.

Consider an application example in which the user subscribes to a service that provides alerts when certain environment conditions (e.g. hazardous air-quality for asthma patients) are detected near his home. The first problem would be to identify what type of environment conditions are hazardous to the particular user, and then identify what type of sensing information would be needed. The next problem would be to find what sensing infrastructure is available, even if it is not maintained or owned by a single entity. Next is to identify where and when to collect data and from what device. Another open problem is how to seamlessly enhance the service as the underlying sensing infrastructure evolves. For instance, more accurate alerts could be provided as more sensors are installed without interrupting the service. Existing solutions, such as those provided in U.S. Pat. No. 7,020,707 and the Dawson-Haggerty article, do not address these issues. A key challenge is to address these problems without having full control or access to the underlying sensing infrastructure, which are frequently formed by heterogeneous WSANs owned by different parties.

In summary, there is a need for a new sensing information service platform that builds on the existing communication infrastructure and protocols to exploit the full extent of an underlying heterogeneous sensing infrastructure while hiding (abstracting) its inherent complexity from the users and application developers. It is also desirable to open up the sensing infrastructure so that new applications and users can take advantage of it, beyond today's closed system approaches.

The current invention further addresses such new applications, in particular those for use in urban city planning. This aspect of the invention relates to apparatus and methods through which the user devices (fixed or mobile) interact with an urban service planning engine (USPE) and with the underlying sensing/lighting infrastructure to obtain recommendations regarding urban planning investments and resource management. That is, the current invention enables user devices (e.g. smart phones, tablets, desktop PCs, etc) to quantify/classify areas and provide a visualization of the attractiveness certain area(s) for new developments (e.g. new businesses, more parking spaces, more security, etc.) based on data collected from urban (sensing/lighting) infrastructure. Consequently, the invention will help users to answer the questions that require information on the attractiveness of a certain geographical area for a specific urban development based on data collected from the underlying heterogeneous sensing and lighting infrastructure.

The above and other exemplary features, aspects, and advantages of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates a conventional Wireless Sensor Network Architecture (WSAN);

Figure 2 illustrates a conventional heterogeneous sensing infrastructure; Figure 3 illustrates sensing broker and the sensing infrastructure according to an embodiment of the invention; Figure 4 illustrates information flow and roles of sensing broker, users and sensing infrastructure according to an embodiment of the invention;

Figure 5 illustrates coordination between sensing broker, users and sensing infrastructure; Figure 6 illustrates information flow and roles of the USPE, sensing broker, users and sensing infrastructure according to an embodiment of the invention;

Figure 7 illustrates coordination between the USPE, sensing broker, users and sensing infrastructure; and,

Figure 8 is a flowchart depicting data collection and service set-up between a user device and the USPE.

It is to be understood that these drawings are solely for purposes of illustrating the concepts of the invention and are not intended as a definition of the limits of the invention. It will be appreciated that the same reference numerals, possibly supplemented with reference characters, where appropriate, have been used throughout to identify corresponding parts.

Further, while the following description of the invention primarily discusses its implementation with respect to Wireless Sensor and Actuator Network (WSAN) embodiments, the invention is not so limited as other types of networks employing remote sensors (wireless or otherwise) are contemplated by the invention.

Figure 1 illustrates a conventional Wireless Sensor and Actuator Network (WSAN). As depicted, a plurality of sensors 1 10 communicate through a Gateway 120 in a Network Infrastructure 130 (for simplicity, only one gateway is depicted although typically the network comprises a plurality of such gateways). The network infrastructure is administered by a Central Management System 160 and is accessible by one or more remote users 140 and 150. As noted above, such networks are usually deployed for a specific purpose, with its own infrastructure to collect, process and present data to the target application and users.

Figure 2 illustrates a heterogeneous sensing infrastructure in which a plurality of WSANs 230, 240 are combined in a network infrastructure 130 in which multiple Central Management Systems (CMS) 210, 220 are associated with respective WSANs 230,240. As depicted in this embodiment, Gateways 225 and 235 are associated with WSAN A 230 and WSAN B 240, respectively. Such networks include one or more OLNs as described above.

Figure 3 expands on the heterogeneous sensing infrastructure of Figure 2 by further depicting a Sensing Broker (SB) 310. As contemplated in this embodiment of the invention, the SB coordinates with one or more heterogeneous WSANs (A and B) to identify, configure, and access sensing data and provide a sensing service to users. Each WSAN may be remotely managed and controlled by a CMS. In various embodiments of the invention devices in the WSANs can be reached through the Gateways 225, 235 or they can be reached directly through the network infrastructure (e.g., Internet). CMSs (A and B) and the SB are also accessible through a generic network infrastructure (e.g. Internet). As so connected, remote users 140, 150 are able to establish service connections with the SB 310 and to subsequently receive relevant sensing information from the SB 310 or directly from one or more WSANs 230, 240.

SB 310 provides an abstract interface between users and the underlying heterogeneous sensing infrastructure. The SB is responsible for collecting the sensing requirements (per user): identifying the sensing capabilities available across heterogeneous WSANs; mapping requirements to sensing capabilities, which is represented by sensing metadata; and configure/collect/aggregate sensing information. The SB communicates with the several WSANs to identify capabilities, configure and collect data. It also communicates with the users to capture user's needs and negotiate/configure the sensing service. The underlying sensing infrastructure may also communicate with the end users, but only to transmit user-specific (relevant) sensing information as configured by the SB.

Figure 4 illustrates the flow of information between the various system components. In particular, that information flow; depicted by arrows 440 and 450 between the SB 310 and users 140, 150; comprises:

• User requirements and preferences

• Service negotiation and configuration

In response to such a user request, the SB 310 :

• Defines sensing requirements (per user) · Aggregates sensing metadata

• Maps requirements to sensing metadata

• Configures/Collects/Aggregates relevant sensing information

This functionality of the Sensing Broker 310 requires communication with each of the WSANs 230, 240 depicted by arrows 460 and 470, respectively. The information provided comprises:

• Capability identification and configuration

• Data collection As noted earlier, relevant sensing information may also flow directly from one or more of the WSANs directly to a user as illustrated by arrows 410 and 420. It should be noted that such communication can occur over the Network Infrastructure 130 depicted in Figure 3 although the invention is not so limited. That is, alternative direct communication paths are contemplated by the invention that do not involve the Network Infrastructure 130 for the delivery of the relevant sensing information to the user. These include various well-known wireless communication means (such as the Internet, Intranet, a wide area network (WAN), a metropolitan area network (MAN), a local area network (LAN), a terrestrial broadcast system, a cable network, a satellite network, Bluetooth communication, etc.), a conventional telephone network (POTS), as well as a dedicated line(s) when preferred for security or other considerations.

Figure 5 illustrates the coordination between the SB 310, users 140, 150, and sensing infrastructure. In particular, it describes an exemplary sequence of steps that are followed to set up the sensing service involving the main system components.

Step 510: The SB 310 communicates with the heterogeneous sensing infrastructure to identify sensing capabilities available. By way of example, this can be performed through a sensing capability publishing protocol in which the WSANs (or the devices therein) publish their capabilities to the SB using a standard way to define sensing metadata including type of sensors, precision and data representation structures, etc;

Step 520: One or more Users 140 contact the SB 310 to initiate a service, which may include negotiation of service terms and configure capabilities. This step also includes description of user needs, which may include type of sensing information, space and time of interest. The SB 310 can provide a user interface to facilitate interaction with users, for example, using standard Web-based technologies, which will hide all the underlying complexity of the heterogeneous sensing infrastructure. In one embodiment, the user may specify an area of interest, time of interest and reporting mode in which the sensing information should be communicated to the user directly or to any destination host(s) requested by the user. In this way, users can not only configure the service to receive sensing information, but they can also use the sensing information in any application or system, as long as the target destination can be reached over a network infrastructure and recognizes the sensing data format. For instance, a city's public safety department can subscribe to the sensing service and configure the service to send traffic accident and hazardous pollution sensing information and alerts to an emergency response unit.

Step 530: After collecting the user inputs, the SB 310 maps them to a sensing requirement description, which will include more detailed information related to the type, accuracy, space and time relevant to the sensing information requested. It should be noted that the user 140 may not understand the specific details about sensing capabilities and devices available, and it is the responsibility of the SB 310 to ensure the user needs are mapped to sensing requirements and capabilities that can be identified in the underlying sensing infrastructure.

Step 540: After the sensing requirements are identified, the SB 310 connects to the appropriate WSANs and configures the sensing measurements needs, which include type of sensing data, frequency and thresholds for on- demand reporting of events. In various embodiments of the invention the appropriate WSANs are determined by comparing the user inputs with one or more tables of sensing capabilities, geolocations and availability times. The user inputs could be high level factors of interest (e.g., air pollution, traffic volume, etc.). In one embodiment The SB would have one or more tables that associates the high level factors with all known types of sensors available, their coverage area, accuracy, and time when they are active. In additional embodiments, the SB may also run one or more algorithms to decide what combination of sensors are best suitable to provide the information required by the user. Such algorithms may be very specific to a particular application. For instance, combining traffic patterns from multiple cameras or combining that with data from other sensors to have a more comprehensive set of data.

Since different WSANs may implement different communication protocols, the SB 310 may have to translate messages between protocol stacks in order to reach the underlying sensing infrastructure. Also, the SB 310 may not require communication directly with sensing devices in the field; instead, it can also communicate with different CMSs (e.g., 210, 220) or other systems that are responsible for control and configuration of the WSAN.

Step 555: This step includes the reporting of the relevant sensing information to the user(s) 140 or their target destinations, as specified in the service agreement. The SB 310 may aggregate and filter the sensing data to identify only the relevant information to be passed on to the users (depicted as step 555. a). Alternatively, sensing information can be transmitted directly from the sensing infrastructure to target user(s) (depicted as step 555. b).

In the present invention the SB 310 may be implemented as any connected device that is able to communicate with users and the various sensor networks, to include the heterogeneous WSANs described in the above embodiments. In further embodiments, the SB may include one or more data communication interfaces (wireless interfaces, wired, etc.). It may also include data processing capabilities to collect and process user data and sensing data. The SB may also include gateway modules (or application bridges) that are used to interface with heterogeneous WSANs. Given that each WSAN may follow a specific protocol stack and application language, the SB is capable of communicating with, and obtaining attributes and data from different WSANs. The SB may be implemented in a centralized entity running on a single device or it may be implemented distributed way, e.g. as an application running on a distributed computing infrastructure (e.g. cloud-computing service). In a further embodiment, the invention comprises personal devices and applications that not only collect the data, but also use such data to make better strategic planning recommendations to users regarding a new/planned urban service, such as investing on new developments or managing available resources (e.g., parking spaces and meter fees). Thus, an example would be a user gathering data for use in planning the renovation of a community's lighting infrastructure, or in deciding what areas of a city should be renovated by adding/removing lighting in order to provide a safer environment. Further examples would include obtaining data in order to decide where to open a new business; where to start a new urban development or renovate a given area of the city; or how to dynamically allocate resources (e.g. police officers, parking spaces, parking violation crews, etc.) to different areas of the city. In each of these examples decision makers would benefit from ubiquitous access to supporting information that quantifies the attractiveness or the varying conditions of a given geographical area. This aspect of the invention provides such information to user devices based on real field data collected by one of more WSANs. In yet another embodiment, the invention provides field data that can be used to validate a planning and/or investment decision. For instance, how to demonstrate/show to customers that a new lighting system installed in a certain neighborhood has contributed to increase the pedestrian traffic and lead to additional businesses.

This aspect of the invention enables a service that helps planners/decision makers to understand attractiveness or needs of areas for certain activities based on real time data collected from a heterogeneous urban sensing infrastructure. In order to enable such service, one of the problems addressed by this invention is how to define the attractiveness or needs of an area, and map those abstract concepts to data requirements. Once the requirements are defined, the system and methods described above can enable the data collection. The invention also enables user devices (e.g. phones, computers, tablets) to access the data, and present the information to users. Furthermore, in order to enable adaptive action based on the data, specific trigger metrics can be defined and monitored for specific applications, actions defined, and information exchanged between decision making engines and field actuators. By way of example, this aspect of the invention deals with the problem of what should trigger a change in the lighting level or parking meter rate within a given area, and how to implement the change in real time once the trigger has been identified. Thus, the current invention addresses service level information and recommendations to user devices based on data obtained from a WSAN, such as an outdoor lighting network.

Figure 6 depicts the proposed urban service planning engine (USPE) 610 and an exemplary system architecture where a sensing broker (SB) 310, as described above, enables access to heterogeneous WSANs (A and B; items 230 and 240, respectively), which form the underlying sensing infrastructure. Other means to collect sensing data may also be possible, such as directly from field devices, including, but not limited to light points equipped with sensors (multiple types of sensors are possible, including, but not limited to motion/traffic, light, noise, pollution, radio frequency, ...). As illustrated, each WSAN may be remotely managed and controlled by a CMS 210, 220. Devices in the WSANs can be reached through gateways 225, 235 or they can be reached directly through a network infrastructure (e.g., Internet). Moreover, the invention contemplates that the CMSs (A and B), SB, and the USPE are each also optionally accessible through a generic network infrastructure, such as the Internet (not illustrated, so as to not overly complicate the figure). That is, in various embodiments of the invention, each component of the system can communicate with each other component over the generic network.

Utilizing the USPE, this embodiment of the invention provides a service to decision makers (users) regarding urban planning investments and resource management. That is, the USPE interacts with user devices (fixed or mobile) and with the underlying sensing and communication infrastructure to implement a service that provides recommendations regarding urban planning investments and resource management. The users of the service may include urban planners, designers, business development officers, real state planners, etc. The proposed service will help users to answer the questions that require information on the attractiveness of a certain geographical area for a specific urban development based on data collected from the underlying heterogeneous sensing infrastructure described earlier above in the description of the invention.

In order to implement the service, the USPE communicates and coordinates with user devices data input collection from users, and interfaces with the infrastructure, e.g. through the SB 310 as shown Figure 6 to provide inputs that can be used to configure and collect the sensing information. The USPE may be implemented as an application that runs in a server or any other connected device that interfaces with the end users, including a user device. The USPE may also be implemented as a system including servers (e.g. running in the cloud) and user access terminals that exchange information. The USPE is also responsible for guiding the user through the initial data collection and problem definition process and mapping the user's planning problem to specific sensing requirements for the infrastructure. Further, the USPE is capable of providing specific recommendations to end users regarding the attractiveness (or fitness) of certain areas to a user planning problem, which may be in the format of graphical visualization and/or recommended actions.

The functions of the SB, as noted above, include collecting the sensing requirements; identifying the sensing capabilities available across heterogeneous WSANs; mapping requirements to sensing capabilities, which is represented by sensing metadata; and configure/collect/aggregate sensing information. In a further embodiment, the invention addresses the process of implementation of a specific application related to providing recommendations/action regarding urban problems. As such, the invention comprises defining the user requirements for a specific problem, and interaction(s) between user devices and the USPE. That is, the USPE can be regarded as a service provider/engine for the user devices, but it is also a "user" of the sensing service provided by the SB, which does not interface with user devices. The USPE also implements the additional capabilities to interface with user devices over any connectivity infrastructure available for advising users anytime anywhere on specific urban service planning questions, namely, mapping the planning problem to sensing requirements, defining the attractiveness index, processing the sensing information received, preparing and presenting the information to end users.

In one embodiment, illustrated in Figure 7, the planning problem being addressed attempting to find the best possible location to open a new business. As depicted Figure 7:

Step 1 : The user device 620 captures and provides input that describes the planning problem. The access could be through a web interface, mobile application, or any other application running on a device that captures and provides the user input to the USPE 610. The user inputs may include:

• Planning task specification: Description of the planning problem including specification of target market, type of business, audience, etc. For a new business development project, the user may input (or select from) information at multiple levels, e.g.:

o Target market (e.g. food industry/retail)

o Type of business (fast food vs. high end)

o Audience (pedestrians/local vs. drivers)

• Area of interest: describe target area, which may be described at different levels, depending on the business, from country, to state, city, zip codes, streets, neighborhood, etc. Although, city and lower levels may be preferred initially due to the local availability of data, the planning problem can also be evaluated in a larger scale (e.g. to compare attractiveness of countries, states or cities for a given development) whenever the underlying data infrastructure is available. The user input may also include the granularity in which geographical locations should be evaluated.

• Attractiveness criteria: the characteristics (geographical/static and human/dynamics) that have impact on the business performance and are key for success, for instance:

o Impact of the quality/availability of lighting in the area

o Impact of traffic:

^■ Components: people, cars, bikes, etc;

^■ Density/volume: low/moderate/high

o Safety conditions: low/medium/high impact on businesses

o Crowd dynamics: how the traffic behaves in the area

^■ Special events: business rely on specific public events in certain areas (concerts, shows, sports events, etc);

o Environment conditions: air quality, noise, waste pollution may impact the business;

It should be noted that the input collection process may adapt to the user input. For instance, as the USPE 610 receives information, it may include/select specific questions to users that are related to the target business aspects. Furthermore, the user may also be requested to rate the relative impact of the different characteristics on the business. The USPE 610 will collect information in attempting to determine a comprehensive and precise specification of the new business development.

Once the user input step is completed, the USPE 610 will define an attractiveness index for the planning problem 710, which can be used to assess and compare the attractiveness of geographical areas for the new business development. In one embodiment, the attractiveness index for a given user can be given by,

Where n is the number of key performance indicators, KPI(u)i for a given user u measured in a normalized scale and w, is the weight of each KPI, which are computed based on the user inputs. Each KPI is a numeric representation of a specific characteristic of the area. Typically, a KPI would be defined for each distinct characteristic provided the user, e.g., traffic, environment, safety, and crowd dynamics. Depending on the planning problem, different KPIs may be included in the attractiveness index calculation. In various embodiments the individual user or an expert (or the system) will choose the initial weightings and/or the key performance indicators. As more people use the system, the system may attempt to learn what should be the best values for these parameters. For example, the system may use one or more validated profile cases to improve selection of the parameters. That is, the system refines the parameter values by comparing a previously computed attractiveness index for a project with results attained after the conclusion of the project (e.g., by selecting parameter values that minimize an error function).

A KPI is a measurable quantity that may include a combination of several metrics. For instance, a traffic KPI (KPI_traffic) may be computed as a combination of several traffic metrics or statistics including density, volume, average speed, etc. Metrics may be classified a higher the better (HB) or lower the better (LB) depending on the business attractiveness criteria.

In this embodiment of the invention, the interaction of the user with the USPE 610 defines the KPI metrics, which represent a high level description of what needs to be computed based on the underlying sensing data. For instance, in order to compute KPI_traffic, the following metrics may be used: density/volume for different components of traffic (vehicles, pedestrian, bikes, etc.), time distribution, flow direction, speed statistics, dwelling times p/ component (how long a pedestrians stay in an area), etc. An example of user interaction with the USPE during the set-up process is illustrated in the flowchart of Figure 8. In step 820, the user is presented information and supplies input that for example, relates to a type of business/service, area of interest (Aol), audience, etc. In various embodiments of the invention, the USPE's control of this input process can vary. That is, the USPE may limit user inputs to selections from a defined list, e.g. by use of dropdown menu(s) presented by the USPE to the user. In a further embodiment, the selection data may be presented to the user by a web server, which server the USPE may periodically update to thus indirectly control the input options. In this manner the server acts as an interface between the user and data transmitted to the USPE (this feature is not illustrated in Figure 8). In further embodiments, the user makes selections at stage 820 that are independent of any limitations imposed by the USPE as to this input. That is, the user may simply rely on Internet research and/or his personal experience.

However determined, this inputted data is transmitted to the USPE at step 830.

At step 840, the USPE processes this data and defines a planning project. By way of example, the planning project may consist of a user ID, a business/service type, an AOI, and an audience). The USPE searches in its database for projects with similar attributes. At step 850 the USPE selects and sends suggested KPIs for the project to the user device for confirmation. These suggestions for the project's KPIs may be based on any available previous history/data for similar projects. They may also be based on associated cost of service for obtaining the data involved.

If at step 860, the user confirms the project KPIs, the USPE receives the acknowledged KPIs and associated costs at step 870. Alternatively, the user selects/changes the KPIs at step 880. The revised KPIs are then sent to the USPE at step 890. As indicated in step 895, the USPE then updates its list of KPIs and associated costs for the project. The process then returns to step 850 where the confirmation of the user is again requested.

Returning to Fig. 7: Step 2: Once the KPIs have been determined, the USPE 610 sends all the KPIs and the KPI metrics 710 to the SB 310, which can then derive the corresponding sensing requirements 720. This step may also include negotiation between of the USPE and SB of sensing service terms and capabilities, if necessary. In addition to the KPI metrics, the USPE may also include additional information to describe the type of sensing information, space and time of interest.

Step 3: This step primarily involves the interaction 730 of the SB 310 with the heterogeneous sensing infrastructure to configure, collect and aggregate the information as described in detail above. In various embodiments, the SB 310 may perform the calculation of each KPI metric, which was provided as user input and report only the end results (metrics). Alternatively, the SB may report the raw data necessary to compute the KPI metrics. After the metrics are computed, the USPE 610 calculates the final attractiveness index 740 for a number of locations within the area of interest.

Step 4: This step includes presentation of the information to the end user 620, which may be done using graphs, maps (heat maps), relative priority lists and additional recommendations for the user (e.g. other areas with high attractiveness outside originally selected target area). For instance, the output may include a list of areas ranked according to the attractiveness or fitness to the business in question. In another embodiment, the attractiveness/fitness numbers can be shown graphically on a map or represented by color scales. In yet another embodiment, the USPE may also classify areas outside the area of interest initially provided by the user device, and provide recommendation of such areas based on their attractiveness value. As one skilled in the art would recognize, the terms processor, processing system, computer or computer system may represent one or more processing units in communication with one or more memory units and other devices, e.g., peripherals, connected electronically to and communicating with the at least one processing unit. Furthermore, the devices illustrated may be electronically connected to the one or more processing units via internal busses, e.g., serial, parallel, ISA bus, microchannel bus, PCI bus, PCMCIA bus, USB, etc., or one or more internal connections of a circuit, circuit card or other device, as well as portions and combinations of these and other communication media, or an external network, e.g., the Internet and Intranet. In other embodiments, hardware circuitry may be used in place of, or in combination with, software instructions to implement the invention. For example, the elements illustrated herein may also be implemented as discrete hardware elements or may be integrated into a single unit.

While there has been shown, described, and pointed out fundamental novel features of the present invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the apparatus described, in the form and details of the devices disclosed, and in their operation, may be made by those skilled in the art without departing from the spirit of the present invention. It is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Substitutions of elements from one described embodiment to another are also fully intended and contemplated. For example, any numerical values presented herein are considered only exemplary and are presented to provide examples of the subject matter claimed as the invention. Hence, the invention, as recited in the appended claims, is not limited by the numerical examples provided herein.

Claims

What is claimed is:

1 . A system to provide a sensing information access service, comprising

a. One or more sensor networks (SNs) each comprising a plurality of sensors and a communication means for communicating within the SN and with one or more external systems;

b. One or more central management systems (CMS) that manages each SN; c. A sensing broker (SB) that coordinates with one or more of the SNs to identify, configure, and access sensing data obtained from the sensors, and to provide a sensing service to users;

d. A means for establishing service connections between the users and the SB for receiving relevant sensing information from the SB.

2. The system of claim 1 , further comprising a means for establishing service connections between the users and one or more of the SNs for receiving relevant sensing information directly from the SNs.

3. The system of claim 2, wherein one or more of said SNs are Wireless Sensor Actuator Networks (WSANs).

4. The system of claim 3, wherein said WSANs are heterogeneous.

5. The system of claim 4, wherein the WSANs may include one or more Outdoor Lighting Networks (OLNs), at least one of the OLNs comprising

e. A Central Management System (CMS) which manages operation, data collection and management of the lighting network;

f. A plurality of light units (LU) at least one of which comprises a control and communication module; g. A plurality of sensors that communicate with the OLN's CMS by being directly coupled with or by communicating with the LUs' communication module.

6. A method to provide a sensing information service between one or more users and one or more Sensor Networks (SNs), each SN comprising at least one sensor and each in communication with a Sensing Broker (SB), said method comprising: a. Inputting by one or more users their main interests and preferences; b. Defining by the SB a sensing requirement specification for a given

application and users;

c. Identifying by the SB what sensing data is required and verifying what data can be obtained from available sensing infrastructure of the SN; and, d. Configuring measurements and events/alerts across the SN to meet the sensing requirement specification.

7. The method of claim 6, further comprising the step of:

e. Negotiating between the users and the SB to obtain agreement on a

service package; said package including the expected sensing information, delivery methods and associated costs.

8. The method of claim 7, wherein the required sensing data is selected from a group of parameters, said parameters selected from the group consisting of: type of data to be sensed, locations of sensors to be monitored, time and periodicity of sensing of data, precision of sensed data, applicable alerts associated with sensed data, and combinations thereof.

9. The method of claim 7, wherein the main interests and preferences of the user are selected from the group consisting of: location, time, type of information of interest, and combinations thereof.

10. The method of claim 6, wherein the SN is a WSAN.

1 1. The method of claim 10, further comprising:

f. Exchanging of sensing meta-data between the SB and the WSANs;

g. Representing the sensing meta-data and sensing information in a uniform format; and,

h. Mapping sensing capabilities from different WSANs to one or more

geographical areas and time domains in order to identify the overall sensing infrastructure, said infrastructure comprising where and when sensing data is available and at what format and precision.

12. The method of claim 10, comprising a further step of communicating relevant sensing information to the users, said step comprising:

i. processing by the SB of sensing information received from the WSANs; and,

j. communicating only the relevant information to the users;

13. The method of claim 12, wherein the step of communicating relevant sensing information to the users, further comprises:

k. Updating by the SB of the sensing information based on the evolution of the sensing infrastructure without interrupting the sensing information service.

14. The method of claim 12, wherein the step of communicating only the relevant information comprises transfer of data directly between at least one WSAN and a user.

15. A system to provide urban service planning support, comprising one or more sensor networks (SNs) each comprising a plurality of sensors and a communication means for communicating within the SN and with one or more external systems; one or more central management systems (CMS) that manage each SN; a sensing broker (SB) that coordinates with one or more of the SNs to identify, configure, and access sensing data and provide a sensing service to users; and, an urban service planning engine (USPE) that defines attractiveness of geographical areas regarding planning decisions based on potential sensing information, obtains available sensing information, and provides recommendations to at least one user related to the attractiveness of a geographical area for a certain planning decision.

16. The system of claim 15, wherein the USPE comprises means for receiving from said at least one user, one or more inputs selected from the group consisting of: types of services of interest (Sol), area of interest (Aol), target market, audience, and combinations thereof.

17. The system of claim 15, further comprising a means for transmitting to said at least one user recommendations and billing/cost information for providing the urban service planning support.

18. The system of claim 15, wherein one or more of said SNs are Wireless Sensor Actuator Networks (WSANs).

19. The system of claim 18, wherein said WSANs may include one or more Outdoor Lighting Networks (OLNs) comprising: a CMS which manages operation, data collection and management of the lighting network; a plurality of light units (LU) including control and communication modules; and, a plurality of sensors coupled with the LUs or that communicate with LUs and the OLN's CMS.

20. The system of claim 19, further comprising a communication means for communicating with one or more of the sensors using a gateway.

21. The system of claim 19, further comprising a communication means for communicating with one or more of the sensors using a network infrastructure.

22. The system of claim 19, further comprising a memory for storing parameters of a previously defined attractiveness determination and the associated

recommendation.

23. A method of providing urban service planning support, said method comprising the steps of: defining an attractiveness index for a geographical area pertaining to a certain planning issue; mapping the attractiveness index to sensing data requirements; configuring the requirements; and, obtaining the data from a sensing/lighting infrastructure.

24. The method of claim 23, further comprising the step of providing information and recommendations to at least one user relating to at least one planning decision.

25. The method of claim 24, wherein said defining step comprises analysis of data pertaining to past recommendations.

26. The method of claim 23, further comprising the steps of defining metrics; detecting changes/patterns based on the metrics that can trigger planning actions; and, notifying at least one user when a triggering event has occurred.

27. The method of claim 23, wherein said attractiveness index is given by:

Where n is the number of key performance indicators, KPI(u)i for a given user u measured in a normalized scale, and w, is the weight of each KPI.

28. The method of claim 27, further comprising the step of adjusting one or more of the Wi values based upon feedback obtained from validated profile cases.

29. The method of claim 27, wherein said defining step comprises utilizing user input.

30. The method of claim 29, wherein said user input is selected from the group consisting of types of services of interest (Sol), area of interest (Aol), target market, audience, and combinations thereof.

31. The method of claim 29, wherein said user input comprises selection of one or more performance indicators or w, s.

32. The method of claim 23, further comprising the step of providing information to at least one user that can be used to evaluate a past planning decision.