WO2016067167A1

WO2016067167A1 - Sensor network for parking management and a method of harvesting data from the network by a mobile device

Info

Publication number: WO2016067167A1
Application number: PCT/IB2015/058149
Authority: WO
Inventors: Oren ELZAM; Eli Israeli; Tamir DALI; Itamar MEIMON; Liron KOPINSKY
Original assignee: Spaceek Ltd.
Priority date: 2014-10-27
Filing date: 2015-10-22
Publication date: 2016-05-06

Abstract

A system and method of data flooding through a parking management sensor network and harvesting this data from the network, comprising providing a parking management sensor network, comprising a plurality of nodes, each comprising communication means; at least one of the plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of the nodes configured to receive and store the recorded data of all other nodes; recording a data change by at least one of the at least one of the plurality of nodes; and sending the data to all the other nodes in the network; detecting by an electronic communication device an advertisement by a sensor's network node comprising data; harvesting by the electronic communication device the data from the advertising node; and uploading the data to a server.

Description

SENSOR NETWORK FOR PARKING MANAGEMENT AND A METHOD OF HARVESTING DATA FROM THE NETWORK BY A MOBILE DEVICE

FIELD OF THE INVENTION

The present invention generally relates to a sensor network and more specifically to a system and a method for data flooding through a parking management sensor network and a method of harvesting this data from the network.

BACKGROUND

Up to date, solutions for efficient parking space management included: intelligent parking guidance systems, convenient pay-and-display machines, and modern car park technology. Some use ultrasound sensors for detecting the presence or absence of a vehicle wherein the sensors are connected using a network to transmit sensing information. Others developed an intelligent car parking system using wireless sensor networks where each parking space is equipped with at least one sensor to detect its availability. Those solutions are mainly implemented using standard star and mesh topologies. Some proposed a parking place availability system using vehicular ad hoc networks based on Wireless-LAN IEEE 802.1 1 to broadcast reports. Some offer a design and implementation considerations for a wireless sensor network that can track available parking spaces in public parking areas in real time and communicate the information to the users.

None of the above provides a system and method for data flooding through a sensor network such as for example Bluetooth low energy sensor network, wherein each node (sensor) in the network receives and stores the information of all the other nodes in the network.

The present invention's data flooding method ensures updated information at any time in any node, thus enabling a user to harvest the network's status (which node is occupied\not occupied) directly from each node using a user application running on the user's mobile communication device and not only from the system server. Moreover, each user may be used as an incidental base station, namely, whenever a user passes by a node, his mobile communication device harvests each node's status and uploads it to the system server, thus eliminating the need for fixed hardware related to managing the uploading of the data to the system server.

The present invention's network is a dynamic network, low cost and energy efficient and does not require a critical mass of users in order to be operative.

SUMMARY

According to an aspect of the present invention there is provided a sensor network, comprising: a plurality of master role nodes; a plurality of slave role nodes, each connected with one of the plurality of master role nodes; and a plurality of gateway role nodes, each connected with its master role node and configured to send information to at least one other master role node; at least one of the plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; each one of the nodes comprises communication means; and each one of the nodes configured to receive and store the recorded data of all other nodes.

Each one of the master role nodes may be configured to receive the recorded data from a sending node selected from the group consisting of its slave role nodes and its gateway role nodes.

Each one of the slave role nodes, other than the sending node, may be configured to receive the recorded data from its master role node.

Each one of a master's gateway role nodes may be configured to receive the recorded data from its master role node.

The at least one of the other master role nodes may be configured to receive the recorded data from its gateway role node.

The other master's slave role nodes may be configured to receive the recorded data from their master role node. The at least one of the slave role nodes and the gateway role nodes may further be configured to periodically advertise its existence upon any data change; and may further comprise a base station configured to detect the advertisement, connect with the at least one advertising node, harvest the recorded data and upload the harvested data to a server.

The at least one of the master role nodes may further be configured to receive a notification that the data was uploaded to the server and to send at least one clear message to the plurality of nodes accordingly.

The base station may comprise a mobile communication device.

The at least one of the plurality of nodes may further be configured to upload the data to a server.

According to another aspect of the present invention there is provided a system comprising: the sensor network above; and a mobile communication device running a user application configured to communicate with the server and continuously receive the data.

Each of the plurality of nodes may comprise sensor represents a parking space.

The user application may be a navigation application configured to receive a destination and provide navigation instructions to a parking space near the destination based on the status of each of the plurality of nodes comprising sensor near the destination.

The status may comprise one of occupied and unoccupied.

The navigation instructions may be continuously updated based on the status.

The user application may be an allocation application configured to allocate a parking space near a destination based on the status of each of the plurality of nodes

comprising sensor and on at least one of at least one rule and at least one parameter.

The destination may be one of a default destination and a destination provided by a user of the allocation application. The at least one parameter may be selected from the group consisting of pregnant woman and disabled person.

The allocation application may further be configured to provide navigation instructions to the allocated parking space.

The user application may be a market place application configured to derive the status of each of the plurality of nodes comprising sensor near a parking lot and to change the parking lot's entry price accordingly.

The status may comprise one of occupied and unoccupied.

The communication means may comprise at least one of wired and wireless

communication.

The wireless communication may comprise Bluetooth low energy.

The at least one of the plurality of nodes may have two roles.

The two roles may be either master and slave roles or master and gateway roles.

According to another aspect of the present invention there is provided a sensor network, comprising: a master role node; and a plurality of slave role nodes, each connected with the master role node; at least one of the nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; each one of the nodes comprises communication means; and each one of the nodes configured to receive and store the recorded data of all other nodes.

The master role node may be configured to receive the recorded data from at least one of its slave role nodes.

Each one of the slave role nodes may be configured to receive the recorded data from its master role node. The at least one of the slave role nodes may further be configured to periodically advertise its existence upon any data change; and may further comprise a base station configured to detect the advertisement, connect with the at least one advertising node, harvest the recorded data and upload the harvested data to a server.

The master role node may further be configured to receive a notification that the data was uploaded to the server and to send at least one clear message to the plurality of nodes accordingly.

The base station may comprise a mobile communication device.

The at least one of the nodes may further be configured to upload the data to a server.

The communication means may comprise at least one of wired communication and wireless communication.

The wireless communication may comprise Bluetooth low energy. The at least one of the nodes may have two roles. The two roles may be master and slave roles.

According to another aspect of the present invention there is provided a method of data flooding through a sensor network, comprising: providing a sensor network, comprising: a plurality of master role nodes; a plurality of slave role nodes, each connected with one of the plurality of master role nodes; and a plurality of gateway role nodes, each connected with its master role node and configured to send information to at least one other master role node; wherein, at least one of the nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of the nodes comprises communication means; receiving the data by a first master role node from a sending node selected from the group consisting of its slave role nodes and its gateway role nodes; storing the data by the first master role node and by the sending node; sending the data by the first master role node to its slave role nodes and its gateway role nodes, other than the sending node; storing the data by the other nodes; broadcasting the data by each one of the other gateway role nodes; receiving and storing the data by a second master role node; sending the data by the second master role node to its slave role nodes and its gateway role nodes; and storing the data by the second master's slave and gateway role nodes.

The communication may comprise at least one of wired and wireless communication. The wireless communication may comprise Bluetooth low energy. The at least one node may be both master and slave. The at least one node may be both master and gateway.

The method may further comprise: advertising by each one of the plurality of slave role nodes and gateway role nodes its existence upon any data change; detecting by an electronic communication device the advertisement; harvesting by the electronic communication device the data from the advertising node; and uploading the data to a server.

According to another aspect of the present invention there is provided a method of navigating to a parking space, comprising: the method above; wherein each of the plurality of nodes comprising sensor may represent a parking space; receiving by a navigation application, running on a mobile communication device, a destination; and providing by the navigation application navigation instructions to a parking space near the destination based on the status of each of the plurality of nodes comprising sensor near the destination.

The status may comprise one of occupied and unoccupied.

The navigation instructions may be continuously updated based on the status.

According to another aspect of the present invention there is provided a method of allocating a parking space, comprising: the method of above; wherein each of the plurality of nodes comprising sensor may represent a parking space; and allocating by an allocation application, running on a mobile communication device, a parking space near a destination based on the status of each of the plurality of nodes comprising sensor and on at least one of at least one rule and at least one parameter.

The destination may be one of a default destination and a destination provided by a user of the allocation application.

The at least one parameter may be selected from the group consisting of pregnant woman and disabled person.

The method may further comprise: providing navigation instructions to the allocated parking space.

According to another aspect of the present invention there is provided a market place method, comprising: the method above; wherein each of the plurality of nodes comprising sensor may represent a parking space; deriving by a market place application, running on a computing device the status of each of the plurality of nodes comprising sensor near a parking lot, the parking lot having an entry price; and changing the parking lot's entry price accordingly.

The electronic communication device may comprise a smartphone.

The method may further comprise: receiving by at least one of the master role nodes a notification that the data was uploaded to the server; and sending by the master role node at least one clear message to the plurality of nodes.

The method may further comprise: uploading by at least one of the plurality of nodes the data to a server.

According to another aspect of the present invention there is provided a method of data flooding through a sensor network, comprising: providing a sensor network, comprising: a master role node; and a plurality of slave role nodes, each connected with the master node; wherein, at least one of the plurality of slave role nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of the nodes comprises communication means; receiving the data upon data change by the master node from one of its slave nodes; storing the data by the master node and by the slave node; sending the data by the master node to its other slave nodes; and storing the data by the other slave nodes.

The communication may comprise at least one of wired and wireless connection. The wireless communication may comprise Bluetooth low energy. The at least one node may be both master and slave.

The method may further comprise: advertising by each one of the plurality of slave role nodes its existence upon any data change; detecting by an electronic communication device the advertisement; harvesting by the electronic communication device the data from the advertising node; and uploading the data to a server.

The electronic communication device may comprise a smartphone.

The method may further comprise: receiving by the master role node a notification that the data was uploaded to the server; and sending by the master role node at least one clear message to the plurality of slave role nodes.

The method may further comprise: uploading by at least one of the nodes the data to a server.

The method may further comprising: receiving by the master role node a notification that the data was uploaded to the server; and sending by the master role node at least one clear message to the plurality of slave role nodes.

According to another aspect of the present invention there is provided a parking management sensor network, comprising: a plurality of nodes, each comprising communication means; at least one of the plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of the nodes configured to receive and store the recorded data of all other nodes. The communication means may comprise at least one of wired communication and wireless communication.

The wireless communication may comprise Bluetooth low energy.

According to another aspect of the present invention there is provided a method of data flooding through a parking management sensor network, comprising: providing a parking management sensor network, comprising: a plurality of nodes, each comprising communication means; at least one of the plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of the nodes configured to receive and store the recorded data of all other nodes; recording a data change by at least one of the at least one of the plurality of nodes; and sending the data to all the other nodes in the network.

The wireless communication may comprise Bluetooth low energy.

According to another aspect of the present invention there is provided a method of harvesting data from a parking management sensor network, comprising: detecting by an electronic communication device an advertisement by a sensor's network node comprising data; harvesting by the electronic communication device the data from the advertising node; and uploading the data to a server.

The electronic communication device may comprise a smartphone.

According to another aspect of the present invention there is provided a method of navigating to parking space near a destination, comprising: communicating by a navigation application, running on a mobile communication device, with a system storing data regarding parking spaces statuses; receiving by the navigation application a destination; and providing by the navigation application navigation instructions to a parking space near the destination based on the data regarding parking spaces statuses. According to another aspect of the present invention there is provided a method of allocating a parking space, comprising: communicating by an allocation application, running on a mobile communication device, with a system storing data regarding parking spaces statuses; and allocating by the allocation application a parking space near a destination based on the statuses and on at least one of at least one rule and at least one parameter.

According to another aspect of the present invention there is provided a method of dynamically changing a parking lot's entry price, comprising: communicating by a market place application, running on a computing device, with a system storing data regarding parking spaces statuses; deriving by the market place application the statuses of parking places near a parking lot, the parking lot having an entry price; and changing the parking lot's entry price accordingly.

BRIEF DESCRIPTION OF THE DRAWINGS

For better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings.

With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a

fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the accompanying drawings:

Fig. 1 A is a schematic view of a Single Star Flood Network (SSFN) according to embodiments of the present invention; Fig. 1 B is a schematic view of a Multi Star Flood Network (MSFN) according to embodiments of the present invention;

Fig. 1 C is a schematic view of the system according to embodiments of the present invention;

Fig. 2 demonstrates exemplary four different signal zones;

Fig. 3A is a general flowchart of the system installation and the network creation process;

Fig. 3B is a flowchart showing stage one of the process of Fig. 3A - the discovery;

Fig. 4 is a flowchart showing the information broadcasting from a Slave to a Master;

Figs. 5A and 5B are flowcharts showing the Gateway assignment algorithm;

Fig. 5C is an exemplary diagram of a MSFN according to embodiments of the present invention;

Fig. 6 shows the Slave's smartphone discovery stage;

Fig. 7 shows the connection between the smartphone harvester and the Slave; Fig. 8 is a flowchart showing the Flooding algorithm; Fig. 9 is a flowchart showing the Clear algorithm;

Fig. 10 demonstrates the implementation of the present invention's sensor network in a parking management system;

Fig. 1 1 is a flowchart showing the process performed by the navigation application according to embodiments of the present invention; and

Fig. 12 is a flowchart showing the process performed by the allocation and navigation application according to exemplary embodiments of the present invention. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is applicable to other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the

phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather the scope of the present invention is defined by the appended claims and includes combinations and sub-combinations of the various features described hereinabove as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description.

The present invention provides a system and method for data flooding through a network such as for example Bluetooth low energy sensor network and a method of harvesting this data from the network.

Fig. 1A is a schematic view of a Single Star Flood Network (SSFN) 100A according to embodiments of the present invention. The Network comprises different nodes, each comprising a microcontroller, a memory and at least one transceiver. The nodes may also comprise a sensor and\or internet connection capabilities. The nodes assume at least one of the following roles: Master role (M) 1 10, Slave role (S) 120 and Gateway role (G) 130 and communicate with each other using wireless protocols such as Bluetooth low energy (BLE). A standard star topology based network is a collection of nodes that are all connected to one Master. An example of this is a Bluetooth Piconet. The network of the present invention is a dynamic, fully reconfigurable network built around many different adjacent star topology based networks. Each node can serve as a Slave, Master, or Gateway, and the network intelligently decides for itself which node serves in which role(s). In general, each node initializes as a Slave and attempts to connect to a nearby Master. If it finds a Master, it connects to it, but if it fails to find a nearby Master, at any time during operation, it turns itself into a Master. If the network ends up with two Masters very close together, one of them will dynamically turn back into a Slave. Finally, once the Master is set up and its Slave nodes are stable, it chooses some of those Slaves to become Gateways in order to forward data to the rest of the network.

According to embodiments of the present invention, the Master node may also be used as a Slave and/or a Gateway as will be explained below.

Fig. 1 B is a schematic view of a Multi Star Flood Network (MSFN) 100B according to embodiments of the present invention. The Multi Star Flood Network comprises a plurality (3 shown) of Single Star Flood Networks 100A that communicate between themselves via the Gateways 130. The design of this network is built around flooding the data from each SSFN throughout the network. Each SSFN intelligently chooses its Gateways 130 to maximize the spread of data that it can achieve, and whenever there is a data change in its SSFN, it uses its Gateways to send that information to all the other SSFNs its gateways can see. Those SSFNs then receive the data and forward it on to any other SSFNs having Gateways that can receive the data. Each SSFN keeps a record at each node of all the data that it has received, to make sure that whenever an incidental Base Station appears, it may harvest the data (as will be explained in detail below) and to make sure that it doesn't forward the same data twice. Periodically, the Master asks all of its Slaves to check what other Masters they can reach, to try and optimize which nodes are used as Gateways.

Fig. 1 C is a schematic view of the system 100C according to embodiments of the present invention. The system 100C comprises the Multi Star Flood Network 100B of Fig. 1 B, a Distributed Base Station (DBS) such as an electronic communication device (e.g. smartphone) 150 running a user application (UA) 160 and a server 170, preferably a cloud server.

Roles:

Master role - configured to collect data from all of its Slaves. Slave role - configured to send all the data it has to its Master, keep a record of all the data its Master has and (optionally) broadcast new data to a DBS.

Gateway role - configured to send data from one SSFN to another SSFN(s) and (optionally) broadcast new data to a DBS.

According to embodiments of the present invention the Master and the Slave may also be used as a DBS if they are internet connected.

Before fully discussing how the network is built, it is necessary to define some parameters pertaining to how the system manages signal strength. Each node has a transceiver which receives messages from other nodes. Based on the interference in the field (e.g. an object in close proximity to the sensor), the received signal strength may change during operation. To manage this, the total signal range of the Master is divided into a number (e.g. four) of different signal zones.

Fig. 2 demonstrates exemplary four different signal zones:

1. Rx 210 is the smallest (nearest) zone and represents, for example, -40% of the total range of the Master 1 10. The Master only accepts nodes into its network (initially) if they fall within Rx. During operation of the network, the interference in the network may change. As such, a node that was in Rx during the creation of the Star Network may no longer be in that range.

2. Ry 220 (e.g. -60% of the signal range) defines the maximum range that allows a node to stay in a network. If the signal strength drops below that, the Slave will have to join a new Master.

3. Rz 230 (e.g. -80% of the signal range) defines the maximum range that the

Master 1 10 accepts connections from any node at all. For example, if a Gateway node of a nearby network is within Rz, the Master receives data from it, but if the Gateway node is farther away than Rz, the Master doesn't receive data from it at all.

4. Rt 240 is the total signal range of the Master 1 10. The system installation and the network creation include a few stages as depicted in Fig. 3A:

1. Nodes (including e.g. Sensors and transceivers) installation in desired locations (31 OA).

2. Self-configuration of the Single Star Flood Network - nodes and their role(s) (320A).

3. Communication with other stable Single Star Flood Networks - Gateway

assignment (330A).

1. Nodes installation in desired locations:

The present invention may be implemented in various applications which dictate the nodes' installation. A number of non-limiting examples may be:

- Parking - the nodes (sensors) may be installed on (or in) parking spots (on the floor/road). The nodes (sensors) may also be installed on the roof or the curbstone if such option is possible.

- Electrical Meters - the nodes (sensors) may be installed on electrical meters.

- Water Readings - the nodes (sensors) may be installed on water meters.

- HVAC - the nodes (sensors) may be installed in buildings to measure

temperature and air flow.

- Smart Home - the nodes (sensors) may be installed on switches or in other desired locations.

The examples will be detailed below.

2. Self-configuration of the Single Star Flood Network - nodes and their roles:

In order to initially create the network, an algorithm is defined so that each node takes at least one of the available roles (Master/Slave/Gateway).

The assumption is that a node is turned ON just after it has been installed.

The self-configuration may be done, for example, according to the logic described below: Stage 1 - discovery

Fig. 3B is a flowchart showing the first stage - the discovery, which consists of building a Single Star Flood Network.

In step 305 a node initiates in a Slave role and tries to connect to a Master. In step 310 the Slave broadcasts its role every Xms for M seconds with GetMasterlnfo broadcast while each Master scans to find Slaves for e.g. 2Xms. In step 320, the algorithm checks if a Master is available in those M seconds. If it is, in step 330, the Master(s) responds to the Slave's broadcast (within Rz) with a MasterlnfoResponse. In step 335 the Slave collects a list of all Masters who have sent a

MasterlnfoResponse. Now, in order to join the Star Network, in step 340 the Slave sends a JoinNetRequest to the nearest Master. The nearest Master must be within acceptable signal strength (Rx). If in step 345 the nearest Master doesn't respond within a certain amount of time, the Slave sends a JoinNetRequest to the next nearest Master (step 350). If the Master does respond, in step 355 the Master "tells" the Slave that it accepts (or doesn't accept) the JoinNetRequest with a

JoinNetResponse. If the Master has accepted the request, in step 360 the Slave joins the Star Network. If the Master hasn't accepted the request the algorithm goes back to step 350. If in step 320 no Master is available for M seconds, the Slave reinitializes in a Master role and accepts Slave connections (step 365).

As mentioned above, a node may take on more than one role. In order to operate in more than one role at the same time, namely, not switch between roles, a node may comprise more than one transceiver or be able to use its one transceiver in different modes, on different channels. In such embodiments, if in the discovery stage the node's first transceiver\channel takes on the Master role, it may automatically assign its other transceiver\channel role as a Slave, hence, this node will be used as both Master and Slave. In such cases, the Slave may be connected to its Master by a direct wired connection, because they are in the same physical unit. In addition, in this case, the Master may assign its node's Slave as Gateway (reducing latency). Stage 2 - Intra Net operation

Fig. 4 is a flowchart showing the information broadcasting from a Slave to a Master. In step 405 the slave algorithm wakes up a Slave's transceiver (due to data from the sensor or at fixed intervals). In step 410 the Slave broadcasts the information every Yms for S seconds or if there is no information, it broadcasts a KeepAlive message. In step 415 the slave algorithm checks if the Slave's Master has responded within these S seconds; if it has, the Master reads the event information from the Slave, writes to the Slave any new information it may have received since the last time that Slave connected and ends the connection (step 420). This guarantees that all of the Slaves keep an up to date list of all the data in their local network. A different approach is also possible, where the Slave requests the Master to only write the info when it is relevant (for example when a Base Station is in range). If in step 415 the Slave's Master hasn't responded, check if a different Master has responded (step 425). If it has, store this Master's ID and its Received Signal Strength Indicator

(RSSI) info (step 430) and go back to step 415. This information will be useful for Gateway assignments that will be explained below. In addition, store the time that this Master responded. This will be used if the Slave becomes a Gateway so it knows when this particular Master is able to receive data. If the Slave's Master hasn't responded within M seconds, but another one has after these M seconds (step 435), attempt to switch to this Master, namely, to a different Single Star Flood Network (step 440). If the Slave has succeeded to switch to this Master, in step 445 it joins the SSFN of the new Master. Otherwise, in step 450 go to stage 1 (step 310 of Fig. 3B). This new Single Star Flood Network must be within a subset of the total range (Rx). This means that the Slave must ignore all Masters that are outside of this range. If in step 435 no other Master has responded, in step 455 go to stage 1 (step 310 of Fig. 3B). Communication with other stable Single Star Flood Networks - Gateway assignment: After going through stages 1 and 2, each Slave now belongs to its own Single Star Flood Network. Now, the data has to be sent from one Star Network to the next. In order to connect SSFNs and create a MSFN, a Gateway is needed. A Gateway is a Slave that can "talk" with additional Masters besides its own.

Figs. 5A and 5B are flowcharts showing the Gateway assignment algorithm.

In order to connect Single Star Networks, the Networks should be stable. The Master of each Single Star Network waits until its network is stable. This is reached when it has a large enough collection of Slaves that are connecting regularly using their KeepAlive messages. A KeepAlive message is sent if there hasn't been any data change in K minutes.

Fig. 5A is a flowchart showing the process of selecting candidate Gateways which is the first stage of the Gateway assignment algorithm. In step 505, a Slave connects with its Master and passes information about all the other Masters it "sees". In step 510, the Master receives a list of other Masters from each of its Slaves. In step 515 the Master determines which of its Slaves can reach the largest number of Masters and decides to select them as candidate Gateways. The decision is made according to the stability of the Slave - The Master chooses a stable Slave (one that has connected consistently and has as strong RSSI as possible).

Fig. 5B is a flowchart showing the second stage of the Gateway assignment algorithm. After performing the first stage of Fig. 5A, in the next step, 520, the Master waits until one of the Gateway assigned Slaves connects, and "tells" it to become a Gateway. In step 530, the Master algorithm checks if the Master has at least two Gateways. If it hasn't, whenever one of the Master's Slaves connects to the Master, the Master reads the list of other Masters that that Slave can see (Fig. 5A) and checks if there is any other Gateway candidate Slave(s) (step 535). If there is, the algorithm goes to step 520. If there isn't, the Master turns back into a Slave and starts the whole initialization process of stage 1 (step 310 of Fig. 3B) all over again (step 540). If in step 530 the Master has at least two Gateways, the algorithm may periodically start an optimization process (step 545) and switch to use another Gateway(s) (step 550). The optimization process may be: - Changing Gateway(s) in order to optimize their usage (save energy, for example).

- Activating an advanced Gateway discovery that will be explained below in conjunction with Fig 5C.

As mentioned above, if a node supports multiple roles, the Master may select its own node's Slave to be a Gateway, which may reduce the range and the latency.

According to embodiments of the invention, a Master may have at least one Gateway.

Fig. 5C is an exemplary diagram of a MSFN according to embodiments of the present invention. In this diagram, each SSFN has two circles. The larger circle is the range of the Master (Rz). The inner circle is a subset of the full range (Ry). For a Slave to belong to a SSFN, it must fall within the smaller circle. This guarantees that if there are nodes between Ry and Rz of a Master, they belong to a different SSFN and may serve as Gateways of that different SSFN to this Master. If a Master has no Gateways or no Gateway broadcasts information to it, restart this Master. This will structure the network differently with different nodes as Masters which may have a better likelihood of seeing other Masters; hence, it will increase the likelihood of creating a Gateway that will connect to adjacent SSFN(s).

As mentioned above, periodically, the Master "tells" the Slave to do an Advanced Gateway Discovery. In the advanced discovery the Master checks which of its Slaves can reach the largest number of unique Masters. Unique Masters are Masters that other Gateways can't see. The Slave connects to all nearby Masters, asking them what SSFNs they can see. For example, if M2 tells Slave S2C to do an Advanced Gateway Discovery, Slave S2C connects to M3 and M5, and asks them what SSFNs they can see. M3 responds with M2 and M5 and M5 responds with M4, M2 and M3. This information tells M2 that choosing a Gateway that can send data to M5 will cause the data to spread more than choosing a Gateway targeting M2.

After configuring the network, the Slaves and the Gateway(s) communicate with their SSFN's Master and transmit messages upon data changes (e.g. change is sensor signal). The Master "listens" to these messages and records them as change events so they can later be published to a Distributed Base Station (DBS) components or to its network sibling Masters (via the SSFN's Gateway(s)). After receiving this information from the Slave(s) and the Gateway(s), the Master updates the Slave with any new data it has received, to keep the Slaves up to date. The Master then forwards any changes it has received to its Gateways (flooding), which then broadcast the information to any nearby Masters. Those Masters then receive the information, add those data entries into their data tables, transmit the new data entries to their slaves and forward the information further down the network using their Gateways. Whenever a Base Station such as electronic communication device (smartphone, for example) appears in the network, it connects to a nearby Slave, reads its data, and uploads it to the cloud server. This then triggers a Clear message in the network, where the Slave "tells" its Master that the data was uploaded, and the Master then floods the Clear message back through the network to help preserve network resources. The Flood and the Clear message will be explained in more detail below.

One of the most unique things about this network is the way it manages sending data to the cloud server without the use of a traditional base station. This is accomplished by using, for example, BLE enabled devices (like regular smartphones) to serve as base stations.

A BLE enabled smartphone may operate in a central role. A central role supports multiple incoming connections and initiates all the connections with the devices in the peripheral role. The network Slaves may operate in a peripheral role. A peripheral role is optimal for devices that support a single connection and are less complex than central devices. Slaves send out a beacon (broadcast) with some basic info every N seconds. Slaves also trigger the communication when a change (e.g. in sensor state) occurs. This means that when new data is available:

- The Slave tries to connect to the Master in order to update it with the data it has.

- The Master sends all the new data it has to the Slave.

- The Slave broadcasts in order to attract a nearby smartphone to connect to it. - The smartphone, with the user application (UA) installed thereon, connects to the Slave and gets the data.

- The smartphone sends the data to the cloud server.

- The smartphone sends an Acknowledgement (ACK) to the Slave.

- The Slave reports to its Master that the data was sent.

- The Master sends a Clear message to the network in order to clear all that data.

Fig. 6 shows the Slave's smartphone discovery stage. The Slave (P) 610 contains the data and advertises it to inform the environment about its existence. An advertisement 615 is a periodic broadcast that can contain data or is just sent out to allow for incoming connections. A smartphone (C) 620, with the user application installed thereon, scans 630 its environment and if an advertisement is detected, it initiates a connection 640 with the Slave.

If the smartphone sets up a connection to the Slave, the smartphone will always be the Master of the link and the Slave will be the Slave. No Master/Slave switch is allowed.

Fig. 7 shows the connection between the smartphone harvester and the Slave. At the end of the harvester's discovery stage (Fig. 6) the harvester (C) 620 sends a data request 710 to the Slave (P) 610. The Slave (P) 610 responds 720 to the data request with data. As long as the smartphone is within the range for the connection and there is new data to receive, steps 710 and 720 will happen again. When no new data is available, there will be no response from the Slave (Slave latency) 730, i.e. the slave is asleep. The Slave latency defines the number of consecutive connection events that may be ignored by the Slave.

After the smartphone has collected the data, it uploads it to the system's cloud server.

That way, each smartphone in the detection zone, running the application, may be used by the system to harvest the data from the network, anywhere, at any time, and upload it to the system's cloud server.

It is possible for multiple base stations (e.g. smartphones) to send the same data up to the cloud server. To manage the server's data and prevent multiple server entries for the same event, when data is sent through the network, it must be uniquely identifiable. This is accomplished by storing the following in each data entry:

1. Star Network ID.

2. Slave ID.

3. Timestamp.

When the data is sent to the server, the server checks to see if this data entry has already been received and discards it if it is redundant. Based on the frequency of data transitions and keepAlive messages, it is possible for the data in the Slave to be slightly out of date. If this happens, no real harm is done, because after syncing with the smartphone and connecting back to the Master, the Master will automatically update the Slave again with any new data that has been received. Then, the Slave starts broadcasting again and reconnects with the smartphone.

According to embodiments of the present invention, a node may also be used as a base station which sends the data to the cloud server. If the node is a Slave or a Gateway, whenever it connects to its Master, it uploads the data derived from the Master to the cloud server. If the node is a Master, whenever it receives data, it may upload it.

In such embodiments, the node has to have wired or wireless communication capabilities in order to send the information to the cloud (e.g. internet).

According to embodiments of the present invention, a smartphone may also be used as a base station which connects to a Master and sends the data to the cloud server. In such embodiments, the smartphone may be in a peripheral role, namely, it advertises and the Master scans and connects to it.

Flooding

Fig. 8 is a flowchart showing the Flooding algorithm. Whenever there is a data event in a Slave in the network (step 810), the Slave forwards that information to its Master (step 820), as defined in Intra Network Operation above. The Master stores this information in its data tables. When any of the Gateways connect to the Master (or if they are already connected) (step 830), the Master passes any new information that it has received to its Gateways (step 840).

After receiving the data from the Master, the Gateway broadcasts any data it has received to nearby Masters (step 850). The Gateway broadcasts for an amount of time that should suffice to reach as many Masters as possible. It makes sure that at least one Master responds with an ACK, so it knows that the data was forwarded to at least one other SSFN. After receiving the data from the Gateway, the receiving Masters store this new piece of data in their data tables, and then forward the data to their own Slaves and Gateways, propagating the data throughout the network (step 860). If this piece of data has already been forwarded by this SSFN, it doesn't get forwarded again (but the hop count may be updated to a new hop count for this piece of data, since the network knows it has reached that level of spread). Whenever any data is forwarded, it contains a hop count field which gets incremented. Data with a lower hop count gets priority to be forwarded. This is because as the hop count increases, the reach of the data spreads exponentially, and data with a higher count is therefore much more likely to already have a good spread in the network. If the Master starts running out of storage space for all the data it has received, it can start randomly overwriting entries that have the highest hop count. This is safe because of the large spread that the data has throughout the network. Practically, this isn't really relevant, because with enough storage space and with frequent enough Base Station syncs (at least one per eight hours in a regular parking scenario, for example), the bigger limitation on the network is the connection latency.

Ideally the MSFN wishes to keep the current state of all the nodes in each SSFN, so the most recent entry for any node is not deleted if it can avoid it.

Because of the flood nature of this network, it is important to clear any data that has already been sent to the cloud server, so that the network resources do not get clogged up. If in step 870 the data has already been sent to the cloud server, go to the Clear algorithm (step 880). Otherwise go back to step 850. The Clear algorithm

Fig. 9 is a flowchart showing the Clear algorithm. After receiving a notification from the DBS that the data has been sent to the cloud server (step 910), the Slave forwards that notification to its Master (step 920). At this point, the Master "knows" two things:

a. All the information from its SSFN before the latest data timestamp has been sent to the cloud.

b. Any information that this Master has received from other SSFNs has been sent to the cloud.

Because of the flood nature of the MSFN, it is very possible that at a given point of time a SSFN has received some, but not all of the information from the other SSFNs.

As such, there are two types of Clear messages (which may be bundled together):

a. Clear SSFN, which clears all the data from the broadcasting Slave's SSFN before a certain timestamp.

b. Clear Data, which clears a particular piece of data that the Master has received from other SSFNs.

To do a Clear, the Master uses the normal flood mechanism described above, but the Clear messages have higher priority than the regular data messages. The Master sends a Clear SSFN message (step 930) to let all other Masters know that all its SSFN's info has already reached the cloud server, and also sends Clear data messages (step 940) for all other pieces of data it has received from other SSFNs. When a Master does a Clear, it always makes sure to maintain the last data (e.g. the status of each sensor) in the network, so that data can be retrieved even without an internet connection.

On-going Network Management:

In normal operation, if two Masters are too close together one of them should shut down. This can be detected with the following:

- A large percentage of the Slaves are not stable.

- A large percentage of the Slaves are all able to see the same Masters. When one of these conditions happens, the Master will reboot as a Slave to reconfigure the network. If a Master has too many Slaves, it can do one of the following:

- Dynamically reduce the range values (Rx, Ry) so that it accepts fewer Slaves.

- Shut itself down to hopefully end up with two Masters in that space.

Every predefined period of time (hours/days), each Slave should rescan to find the nearest Master. If one of the Slaves tries to connect to the Master, but the signal strength is below a certain threshold (Ry), it should get removed from the SSFN and try and find a new Master. This will happen if one of the Slaves from the Network tries to connect to the Master and the signal strength is too low. The Master will just start ignoring that Slave and the Slave will eventually either connect to a new Master or become a Master itself. If a Master can see another Master(s) and all of its Slaves can see other Master(s) it should become a Slave. If a Master can see another Master(s) and it has no Slaves, it should become a Slave.

According to embodiments of the present invention, the nodes may be connected to each other by wired connection hence, no transceiver is needed.

Power management

The Master is the largest power-consumer in the network. In order to reduce the Master's power consumption, it may only scan for a short percentage of each second (e.g. 20-30ms/second).

The Slaves advertise a periodic KeepAlive message. If a sensor status change occurs the Slave advertises status change message at a frequency higher than the Master's scan frequency (e.g. 10-15ms intervals) to make sure that it can hit the Master. It does this continuously until the Master responds. If after a certain amount of time the Master has not responded, it tries to find another Master as described above. This means that while it is advertising, the Slave uses a fair amount of power, but since it only does so when it has data to send, the overall power consumption of the Slave is very low as compared to the Master which scans every fixed interval (e.g. every second). The Gateways are in an in-between state. They have to try and connect to their Masters and send data to other Masters. This means that the Gateways do not need to advertise more than necessary and they have to try and focus their advertising broadcasts to when the other Masters are scanning, so that the data gets spread through the network without wasting too much power. When flooding data to other networks, since the Gateway "knows" the approximate time when each of the Masters nearby is expecting data (based on when those Masters responded to the Gateway node during the original Discovery phase), it can broadcast selectively to try and preserve power and only send information when the other Master can receive it.

Once in a while, at predetermined periods or according to the nodes' battery status, a SSFN may start stage 1 - the discovery, all over again. That way, at each discovery, the process may be configured to choose a different node to serve as a Master, thus utilizing each node's battery to the maximum.

The present invention may be used in several implementations:

1. Parking - as a parking aid system, indicating free and occupied parking spots using sensors installed in the parking spots and the present invention's sensor network that manages the information. The sensors are used to detect available parking spaces and send the current status of each parking space to the network.

Fig. 10 demonstrates the implementation of the present invention's sensor network in a parking management system. Sensors 1 1 10 are installed in parking spots. Each sensor senses the parking spot status (occupied\ not occupied) and whenever a status change occurs, the information is flooded 1 1 15 (propagated) to all the other nodes in the network (as described above, some of the nodes may not comprise a sensor).

A user, carrying a mobile communication device 1 120 (MCD) running the present invention's user application 1 130, may view the network's status in a number of ways: 1. Directly from the system's nodes - whenever a user passes by a sensor that has information to broadcast, a connection 1 140 is made between the broadcasting nodel 145 and the user's MCD 1 120 running the user application 1 130, and the user harvests the network's status. In this way, the MCD does not have to be connected to the system server (e.g. when it is in an underground parking lot with no internet reception).

Each node\sensor 1 1 10 may be a broadcasting node 1 145; the different number is purely for explanation purposes.

2. Directly from the system's nodes (as in 1) and from the system server. In this way, the user may harvest the network's status from the broadcasting node and receive it from the system server. In order to receive the network's status from the server, the user's MCD has to be internet connected.

3. From the system server only - in case that a user is not located in the range for harvesting the information directly from any of the network's nodes (e.g. at home), he may receive the information from the system server 1 160 and view the network's status in the user application 1 130. In this case the user's MCD has to be internet connected.

The user's MCD may be used as a base station for uploading 1 150 the parking information it harvested from the broadcasting node 1 145 to the system server 1 160 (via the user application 1 130). In order to do so, the user's MCD has to be internet connected. Electrical Meter Readings - each electric meter could be attached to the present invention's network, and instead of having to get out and read each meter, the inspector could just drive around and mine the data from the network. Most of the data would be sent throughout the network, and he wouldn't have to drive very much to receive all the data. This is especially useful in apartment buildings where the meters are not all in the same place. Moreover, tenants who have the user application may assist by harvesting the information instead of the inspector. 3. Water Meter Readings - same as Electrical Meter Readings.

4. HVAC - large facilities could place temperature sensors connected to the present invention's network throughout the building, and then connect to the network anywhere using a smartphone or other device to make sure the building is being heated or cooled appropriately.

5. Smart Home - a user could have all of his lights and other house utilities

integrated into the present invention's network. If a user wants to turn on a light in his house, his smartphone could connect to the network and send a message to turn on a particular light, and that information would flood the network until the light turns on. The sensors may be placed on switches or in other parts of the house in order to control the light switches with other components which are attached to the network.

For example, one could have a sensor which is connected to a light in a particular room. When that sensor detects that it is dark, it could send that information through the network and a different node, which is connected to a light switch, could turn on the light.

Any authorized user may connect to the network to receive the current state of all lights and other appliances in the house.

According to embodiments of the invention, the nodes are not necessarily sensors. Some nodes may be sensors, other nodes, may be nodes without a sensor for extending the range of the network and other nodes may be able to do things based on information in the network. For example, in Parking, a node may be a red/green light which shows parking occupancy.

In HVAC a node may be a control panel for someone to view the temperature and change it without using an app.

In the smart home, a node may be a switch to turn on/off a light, open the blinds, turn on the coffee machine, etc.

According to embodiments of the present invention, there are several applications which may use the system of the present invention. Navigation application

The navigation application provides navigation instructions to an optimal unoccupied parking space near the user's requested destination (e.g. an address).

The optimal unoccupied parking space may be configured by the user's preferences such as, for example, the distance from the destination, the parking space price, time to arrival, etc. For example, the user may choose the maximal distance of the parking space from his requested destination to be 100 meters and the parking space price to be maximum 2 dollars per hour. The navigation application will find the parking space that complies with those two constraints.

Fig. 1 1 is a flowchart showing the process performed by the navigation application according to embodiments of the present invention. In step 1010, the application receives from the user a requested destination (e.g. an address). In step 1020, the application communicates with a system providing data regarding parking spaces such as, for example, the system of the present invention or any other system capable of providing data regarding parking spaces using sensors, cameras, etc. in order to find a currently optimal parking space. Data regarding the parking spaces may be, for example, the status of the sensor mounted in each parking space (occupied or unoccupied). The currently optimal parking space is an unoccupied parking space in close proximity to the user's destination which fits the user's predetermined preferences as mentioned above. In step 1030, the application navigates the user to the currently optimal parking space. In step 1040, the application checks if the user has arrived to the currently optimal parking space. If he has, in step 1050, the application may notify him that he has arrived. Alternatively, the application may stop the navigation and wait for instructions. If the user has not arrived to the currently optimal parking space, in step 1060, the application checks if the currently optimal parking space has changed. The currently optimal parking space may change, for example, because somebody parked in this parking space and it is no longer available, another parking space has become available and is currently optimal (e.g. closer to the user's destination), etc. If the currently optimal parking space has not changed, the application goes back to step 1040. If the currently optimal parking space has changed, in step 1070, the application navigates to the new currently optimal parking space and goes back to step 1040. Allocation and navigation (A&N) application

The A&N application enables a driver to be navigated to a specific parking space allocated by a parking operator based on the driver's defined parameters and a set of rules. According to embodiments of the invention, the driver is an employee and the parking operator is an employer thus, for example, a parking space close to the elevator may be allocated to a pregnant woman, a parking space close to the elevator may be allocated to an employee who complies with the terms of carpool, etc. Each employee's parameters are defined in a database managed by the employer. The employer may define parameters, such as for example, a pregnant woman, a disabled employee, etc. or may define a set of rules that when complied with by the employee enable him to park in a defined parking space.

According to embodiments of the invention, the driver is a person who is attending an event (sports game, show, conference, etc.) and the parking operator is the event's manager. In this example, the driver has to download a specific A&N application dedicated to the event in order to be recognized by the event's manager as attending the event. Each driver's parameters are defined in a database managed by the event's manager in order to allocate him a parking space based on his parameters and a set of rules (as mentioned above).

Fig. 12 is a flowchart showing the process performed by the A&N application according to exemplary embodiments of the present invention. In step 1205 the user activates the application. In step 1210 the application optionally receives from the user the required destination (e.g. work address or "work" tag, or an event address). Alternatively, the application may be configured to navigate to a specified address as default when activated. For the purpose of explanation, the flowchart continues with the example of employee and employer. In step 1220, the application communicates with the employer's data base in order to fetch the user's (employee's) parameters and checks whether the employee complies with any rule, for example, authorized as using carpool, drive in an average driving speed of less than X Km/h (e.g. as detected by the smartphone's sensors), etc. According to embodiments of the invention, each employee's A&N application, installed on each employee's mobile communication device, is configured to advertise its existence. In order to check if the employee complies with the terms of carpool, the application scans to find if there are any other users, who are employees of the same organization and have the application installed on their mobile communication device, in close proximity to the employee (the user), for example using Bluetooth low energy technology. Additionally, the user's application checks whether the detected devices travel a certain distance together with the user's device, for example, by monitoring the user's GPS movement while maintaining reasonable RF signal strength to the detected devices. If there are, as defined by the carpool rule, for example, a driver plus three passengers, and the passengers travel with the driver, the user (employee) is authorized as using carpool. In step 1230 the application navigates the user to a parking space allocated according to the rules he complied with and its parameters, e.g. a "premium" parking place reserved for carpool drivers.

According to embodiments of the invention, the A&N application may be configured to inform the parking operator when an unauthorized driver parks in a disabled person space, a carpool space, etc.

Market place application

The market place application, running on a computing device, enables a parking lot operator to monitor available parking spaces in its surrounding. The ability to monitor the available parking spaces in the parking lot's surrounding enables the parking lot operator to dynamically change his parking lot's entry price. The application is connected to a system providing data regarding parking spaces such as, for example, the system of the present invention or any other system capable of providing data regarding parking spaces using sensors, cameras, etc. in order to map or quantify the number of available parking spaces (e.g. in a predetermined radius) in real time.

According to embodiments of the invention, the application may enable the operator to define parameters such as monitoring radius, upper limit, lower limit, alerts, etc., define automatic price change according to the available parking spaces in the lot's surrounding and (optionally) according to the available parking spaces in the lot, for example, 10 available parking spaces in the lot's surrounding - 10 dollars, 25 available parking spaces in the lot's surrounding - 8 dollars, 50 available parking spaces in the lot's surrounding - 6 and so forth.

According to embodiments of the invention, a parking lot's operator may detect users whose destination is in a predefined radius from his lot and offer them a lower price. The parking lot's operator may be connected to the system's cloud (170 of Fig. 1 C or 1 160 of Fig. 10) thus when a user is offered to park in a parking spot existing in the operator's predefined radius, the operator is notified about it. For example, the predefined radius is 150 meters and a user is offered to park within this radius, 120 meters from the parking lot. The parking lot's operator may send a message to that user and offer him a lower price in order to motivate him to park at his parking lot. According to embodiments of the invention, the user may communicate with the operator in order to negotiate the price (e.g. using messages).

While this invention has been described as having an exemplary design, the present invention may be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains. For example, using wireless technologies other than BLE (e.g. ANT+) or topologies other than star topology (e.g. mesh).

Claims

A sensor network, comprising:

- a plurality of master role nodes;

- a plurality of slave role nodes, each connected with one of said plurality of master role nodes; and

- a plurality of gateway role nodes, each connected with its master role node and configured to send information to at least one other master role node; at least one of said plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; each one of said nodes comprises communication means; and each one of said nodes configured to receive and store said recorded data of all other nodes.

The sensor network of claim 1 , wherein each one of said master role nodes is configured to receive said recorded data from a sending node selected from the group consisting of its slave role nodes and its gateway role nodes.

The sensor network of claim 2, wherein each one of said slave role nodes, other than said sending node, is configured to receive said recorded data from its master role node.

The sensor network of claim 2, wherein each one of a master's gateway role nodes is configured to receive said recorded data from its master role node.

The sensor network of claim 4, wherein at least one of said other master role nodes is configured to receive said recorded data from its gateway role node.

The sensor network of claim 5, wherein said other master's slave role nodes are configured to receive said recorded data from their master role node.

7. The sensor network of claim 1 , wherein at least one of said slave role nodes and said gateway role nodes is further configured to periodically advertise its existence upon any data change; and further comprising a base station configured to detect said advertisement, connect with said at least one advertising node, harvest said recorded data and upload said harvested data to a server.

8. The sensor network of claim 7, wherein at least one of said master role nodes is further configured to receive a notification that the data was uploaded to the server and to send at least one clear message to said plurality of nodes accordingly.

9. The sensor network of claim 7, wherein said base station comprises a mobile communication device.

10. The sensor network of claim 1 , wherein at least one of said plurality of nodes is further configured to upload said data to a server.

1 1. A system comprising:

- the sensor network of claim 10; and

- a mobile communication device running a user application configured to communicate with said server and continuously receive said data.

12. The system of claim 1 1 , wherein each of said plurality of nodes comprising

sensor represents a parking space.

13. The system of claim 12, wherein said user application is a navigation application configured to receive a destination and provide navigation instructions to a parking space near said destination based on the status of each of said plurality of nodes comprising sensor near said destination.

14. The system of claim 13, wherein said status comprises one of occupied and unoccupied.

15. The system of claim 13, wherein said navigation instructions are continuously updated based on said status.

16. The system of claim 12, wherein said user application is an allocation application configured to allocate a parking space near a destination based on the status of each of said plurality of nodes comprising sensor and on at least one of at least one rule and at least one parameter.

17. The system of claim 16, wherein said destination is one of a default destination and a destination provided by a user of said allocation application.

18. The system of claim 16, wherein said at least one parameter is selected from the group consisting of pregnant woman and disabled person.

19. The system of claim 16, wherein said allocation application is further configured to provide navigation instructions to said allocated parking space.

20. The system of claim 12, wherein said user application is a market place

application configured to derive the status of each of said plurality of nodes comprising sensor near a parking lot and to change said parking lot's entry price accordingly.

21. The system of claim 19, wherein said status comprises one of occupied and unoccupied.

22. The sensor network of claim 10, wherein at least one of said master role nodes is further configured to receive a notification that the data was uploaded to the server and to send at least one clear message to said plurality of nodes accordingly.

23. The sensor network of claim 1 , wherein said communication means comprise at least one of wired and wireless communication.

24. The sensor network of claim 23, wherein said wireless communication comprises Bluetooth low energy.

25. The sensor network of claim 1 , wherein at least one of said plurality of nodes has two roles.

26. The sensor network of claim 25, wherein said two roles are either master and slave roles or master and gateway roles.

27. A sensor network, comprising:

- a master role node; and

- a plurality of slave role nodes, each connected with said master role node; at least one of said nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; each one of said nodes comprises communication means; and each one of said nodes configured to receive and store said recorded data of all other nodes.

28. The sensor network of claim 27, wherein said master role node is configured to receive said recorded data from at least one of its slave role nodes.

29. The sensor network of claim 28, wherein each one of said slave role nodes is configured to receive said recorded data from its master role node.

30. The sensor network of claim 27, wherein at least one of said slave role nodes is further configured to periodically advertise its existence upon any data change; and further comprising a base station configured to detect said advertisement, connect with said at least one advertising node, harvest said recorded data and upload said harvested data to a server.

31. The sensor network of claim 30, wherein said master role node is further

configured to receive a notification that the data was uploaded to the server and to send at least one clear message to said plurality of nodes accordingly.

32. The sensor network of claim 30, wherein said base station comprises a mobile communication device.

33. The sensor network of claim 27, wherein at least one of said nodes is further configured to upload said data to a server.

34. The sensor network of claim 33, wherein said master role node is further

35. The sensor network of claim 27, wherein said communication means comprise at least one of wired communication and wireless communication.

36. The sensor network of claim 35, wherein said wireless communication comprises Bluetooth low energy.

37. The sensor network of claim 35, wherein at least one of said nodes has two

roles.

38. The sensor network of claim 37, wherein said two roles are master and slave roles.

39. A method of data flooding through a sensor network, comprising:

providing a sensor network, comprising:

- a plurality of master role nodes;

- a plurality of slave role nodes, each connected with one of said

plurality of master role nodes; and

- a plurality of gateway role nodes, each connected with its master role node and configured to send information to at least one other master role node; wherein, at least one of said nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of said nodes comprises communication means; receiving said data by a first master role node from a sending node selected from the group consisting of its slave role nodes and its gateway role nodes; storing said data by said first master role node and by said sending node; sending said data by said first master role node to its slave role nodes and its gateway role nodes, other than said sending node; storing said data by said other nodes; broadcasting said data by each one of said other gateway role nodes; receiving and storing said data by a second master role node; sending said data by said second master role node to its slave role nodes and its gateway role nodes; and storing said data by said second master's slave and gateway role nodes.

40. The method of claim 39, wherein said communication comprises at least one of wired and wireless communication.

41. The method of claim 40, wherein said wireless communication comprises

Bluetooth low energy.

42. The method of claim 39, wherein at least one node is both master and slave.

43. The method of claim 39, wherein at least one node is both master and gateway.

44. The method of claim 39, further comprising: advertising by each one of said plurality of slave role nodes and gateway role nodes its existence upon any data change; detecting by an electronic communication device said advertisement; harvesting by said electronic communication device said data from said advertising node; and uploading said data to a server.

45. A method of navigating to a parking space, comprising:

- the method of claim 44; wherein each of said plurality of nodes comprising sensor represents a parking space;

- receiving by a navigation application, running on a mobile

communication device, a destination; and

- providing by said navigation application navigation instructions to a parking space near said destination based on the status of each of said plurality of nodes comprising sensor near said destination.

46. The method of navigating to a parking space of claim 45, wherein said status comprises one of occupied and unoccupied.

47. The method of navigating to a parking space of claim 45, wherein said navigation instructions are continuously updated based on said status.

48. A method of allocating a parking space, comprising:

- the method of claim 44; wherein each of said plurality of nodes comprising sensor represents a parking space; and

- allocating by an allocation application, running on a mobile communication device, a parking space near a destination based on the status of each of said plurality of nodes comprising sensor and on at least one of at least one rule and at least one parameter.

49. The method of allocating a parking space of claim 48, wherein said destination is one of a default destination and a destination provided by a user of said allocation application.

50. The method of allocating a parking space of claim 48, wherein said at least one parameter is selected from the group consisting of pregnant woman and disabled person.

51. The method of allocating a parking space of claim 48, further comprising: - providing navigation instructions to said allocated parking space.

52. A market place method, comprising:

- deriving by a market place application, running on a computing device the status of each of said plurality of nodes comprising sensor near a parking lot, said parking lot having an entry price; and

- changing said parking lot's entry price accordingly.

53. The method of claim 44, wherein said electronic communication device

comprises a smartphone.

54. The method of claim 44, further comprising:

receiving by at least one of said master role nodes a notification that said data was uploaded to the server; and

sending by said master role node at least one clear message to said plurality of nodes.

55. The method of claim 39, further comprising:

uploading by at least one of said plurality of nodes said data to a server.

56. The method of claim 54, further comprising:

57. A method of data flooding through a sensor network, comprising:

providing a sensor network, comprising:

- a master role node; and

- a plurality of slave role nodes, each connected with said master node; wherein, at least one of said plurality of slave role nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of said nodes comprises communication means; receiving said data upon data change by said master node from one of its slave nodes; storing said data by said master node and by said slave node; sending said data by said master node to its other slave nodes; and storing said data by said other slave nodes.

58. The method of claim 57, wherein said communication comprises at least one of wired and wireless connection.

59. The method of claim 58, wherein said wireless communication comprises

Bluetooth low energy.

60. The method of claim 57, wherein at least one node is both master and slave.

61. The method of claim 57, further comprising: advertising by each one of said plurality of slave role nodes its existence upon any data change; detecting by an electronic communication device said advertisement; harvesting by said electronic communication device said data from said advertising node; and uploading said data to a server.

62. The method of claim 61 , wherein said electronic communication device comprises a smartphone.

63. The method of claim 61 , further comprising: receiving by said master role node a notification that said data was uploaded to the server; and

sending by said master role node at least one clear message to said plurality of slave role nodes.

64. The method of claim 57, further comprising:

uploading by at least one of said nodes said data to a server.

65. The method of claim 64, further comprising:

receiving by said master role node a notification that said data was uploaded to the server; and

66. A parking management sensor network, comprising: a plurality of nodes, each comprising communication means; at least one of said plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of said nodes configured to receive and store said recorded data of all other nodes.

67. The parking management sensor network of claim 66, wherein said

communication means comprise at least one of wired communication and wireless communication.

68. The parking management sensor network of claim 67, wherein said wireless communication comprises Bluetooth low energy.

69. A method of data flooding through a parking management sensor network, comprising:

providing a parking management sensor network, comprising: a plurality of nodes, each comprising communication means; at least one of said plurality of nodes comprises a sensor and is configured to record data upon data change indicated by its sensor; and each one of said nodes configured to receive and store said recorded data of all other nodes; recording a data change by at least one of said at least one of said plurality of nodes; and sending said data to all the other nodes in the network.

70. The method of claim 69, wherein said communication means comprise at least one of wired communication and wireless communication.

71. The method of claim 70, wherein said wireless communication comprises

Bluetooth low energy.

72. A method of harvesting data from a parking management sensor network,

comprising:

detecting by an electronic communication device an advertisement by a sensor's network node comprising data;

harvesting by said electronic communication device said data from said advertising node; and

uploading said data to a server.

73. The method of claim 72, wherein said electronic communication device

comprises a smartphone.

74. A method of navigating to parking space near a destination, comprising:

- communicating by a navigation application, running on a mobile communication device, with a system storing data regarding parking spaces statuses;

- receiving by said navigation application a destination; and

- providing by said navigation application navigation instructions to a parking space near said destination based on said data regarding parking spaces statuses.

75. A method of allocating a parking space, comprising: - communicating by an allocation application, running on a mobile communication device, with a system storing data regarding parking spaces statuses; and

- allocating by said allocation application a parking space near a destination based on said statuses and on at least one of at least one rule and at least one parameter.

76. A method of dynamically changing a parking lot's entry price, comprising:

- communicating by a market place application, running on a computing device, with a system storing data regarding parking spaces statuses;

- deriving by said market place application said statuses of parking places near a parking lot, said parking lot having an entry price; and changing said parking lot's entry price accordingly.