POINT-TO-POINT COMMUNICATION WITHIN A MESH NETWORK

Abstract

A method and system provide receiving communications via either a short address or a long address. The method may include, responsive to receiving a packet, parsing a packet header. The method may include computing a response to the packet. The method may include, responsive to determining the packet includes a short address addressee, transmitting the response via a mesh network. The method may include, responsive to determining the packet includes a long address addressee, transmitting the response via a point-to-point protocol.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to the following United States provisional patent applications which are incorporated herein by reference in their entirety:

• • Ser. No. 60/989,957 entitled “Point-to-Point Communication within a Mesh Network”, filed Nov. 25, 2007 (TR0004-PRO);
  • Ser. No. 60/989,967 entitled “Efficient And Compact Transport Layer And Model For An Advanced Metering Infrastructure (AMI) Network,” filed Nov. 25, 2007 (TR0003-PRO);
  • Ser. No. 60/989,958 entitled “Creating And Managing A Mesh Network Including Network Association,” filed Nov. 25, 2007 (TR0005-PRO);
  • Ser. No. 60/989,964 entitled “Route Optimization Within A Mesh Network,” filed Nov. 25, 2007 (TR0007-PRO);
  • Ser. No. 60/989,950 entitled “Application Layer Device Agnostic Collector Utilizing ANSI C12.22,” filed Nov. 25, 2007 (TR0009-PRO);
  • Ser. No. 60/989,953 entitled “System And Method For Real Time Event Report Generation Between Nodes And Head End Server In A Meter Reading Network Including From Smart And Dumb Meters,” filed Nov. 25, 2007 (TR0010-PRO);
  • Ser. No. 60/989,975 entitled “System and Method for Network (Mesh) Layer And Application Layer Architecture And Processes,” filed Nov. 25, 2007 (TR0014-PRO);
  • Ser. No. 60/989,959 entitled “Tree Routing Within a Mesh Network,” filed Nov. 25, 2007 (TR0017-PRO);
  • Ser. No. 60/989,961 entitled “Source Routing Within a Mesh Network,” filed Nov. 25, 2007 (TR0019-PRO);
  • Ser. No. 60/989,962 entitled “Creating and Managing a Mesh Network,” filed Nov. 25, 2007 (TR0020-PRO);
  • Ser. No. 60/989,951 entitled “Network Node And Collector Architecture For Communicating Data And Method Of Communications,” filed Nov. 25, 2007 (TR0021-PRO);
  • Ser. No. 60/989,955 entitled “System And Method For Recovering From Head End Data Loss And Data Collector Failure In An Automated Meter Reading Infrastructure,” filed Nov. 25, 2007 (TR0022-PRO);
  • Ser. No. 60/989,952 entitled “System And Method For Assigning Checkpoints To A Plurality Of Network Nodes In Communication With A Device Agnostic Data Collector,” filed Nov. 25, 2007 (TR0023-PRO);
  • Ser. No. 60/989,954 entitled “System And Method For Synchronizing Data In An Automated Meter Reading Infrastructure,” filed Nov. 25, 2007 (TR0024-PRO);
  • Ser. No. 60/992,312 entitled “Mesh Network Broadcast,” filed Dec. 4, 2007 (TR0027-PRO);
  • Ser. No. 60/992,313 entitled “Multi Tree Mesh Networks”, filed Dec. 4, 2007 (TR0028-PRO);
  • Ser. No. 60/992,315 entitled “Mesh Routing Within a Mesh Network,” filed Dec. 4, 2007 (TR0029-PRO);
  • Ser. No. 61/025,279 entitled “Point-to-Point Communication within a Mesh Network”, filed Jan. 31, 2008 (TR0030-PRO), and which are incorporated by reference.
  • Ser. No. 61/025,270 entitled “Application Layer Device Agnostic Collector Utilizing Standardized Utility Metering Protocol Such As ANSI C12.22,” filed Jan. 31, 2008 (TR0031-PRO);
  • Ser. No. 61/025,276 entitled “System And Method For Real-Time Event Report Generation Between Nodes And Head End Server In A Meter Reading Network Including Form Smart And Dumb Meters,” filed Jan. 31, 2008 (TR0032-PRO);
  • Ser. No. 61/025,282 entitled “Method And System for Creating And Managing Association And Balancing Of A Mesh Device In A Mesh Network,” filed Jan. 31, 2008 (TR0035-PRO);
  • Ser. No. 61/025,271 entitled “Method And System for Creating And Managing Association And Balancing Of A Mesh Device In A Mesh Network,” filed Jan. 31, 2008 (TR0037-PRO);
  • Ser. No. 61/025,287 entitled “System And Method For Operating Mesh Devices In Multi-Tree Overlapping Mesh Networks”, filed January 31, 2008 (TR0038-PRO);
  • Ser. No. 61/025,278 entitled “System And Method For Recovering From Head End Data Loss And Data Collector Failure In An Automated Meter Reading Infrastructure,” filed Jan. 31, 2008 (TR0039-PRO);
  • Ser. No. 61/025,273 entitled “System And Method For Assigning Checkpoints to A Plurality Of Network Nodes In Communication With A Device-Agnostic Data Collector,” filed Jan. 31, 2008 (TR0040-PRO);
  • Ser. No. 61/025,277 entitled “System And Method For Synchronizing Data In An Automated Meter Reading Infrastructure,” filed Jan. 31, 2008 (TR0041-PRO); and
  • Ser. No. 61/094,116 entitled “Message Formats and Processes for Communication Across a Mesh Network,” filed Sep. 4, 2008 (TR0049-PRO).

This application hereby references and incorporates by reference each of the following United States patent applications filed contemporaneously herewith:

• • Ser. No. ______ entitled “Efficient And Compact Transport Layer And Model For An Advanced Metering Infrastructure (AMI) Network,” filed Nov. 21, 2008 (TR0003-US);
  • Ser. No. ______ entitled “Communication and Message Route Optimization and Messaging in a Mesh Network,” filed Nov. 21, 2008 (TR0007-US);
  • Ser. No. ______ entitled “Collector Device and System Utilizing Standardized Utility Metering Protocol,” filed Nov. 21, 2008 (TR0009-US);
  • Ser. No. ______ entitled “Method and System for Creating and Managing Association and Balancing of a Mesh Device in a Mesh Network,” filed Nov. 21, 2008 (TR0020-US); and
  • Ser. No. ______ entitled “System And Method For Operating Mesh Devices In Multi-Tree Overlapping Mesh Networks”, filed Nov. 21, 2008 (TR0038-US).

FIELD OF THE INVENTION

This invention pertains generally to methods and systems for providing local communication within a mesh network without necessarily associating with the mesh network.

BACKGROUND OF THE INVENTION

A mesh network is a wireless network configured to route data between mesh device nodes within the network. It allows for continuous connections and reconfigurations around broken or blocked paths by retransmitting messages from node to node until a destination is reached. Mesh networks differ from other networks in that nodes can all connect to each other via multiple hops. Thus, mesh networks are self-healing: the network remains operational when a node or a connection fails.

Advanced Metering Infrastructure (AMI) or Advanced Metering Management (AMM) are systems that measure, collect and analyze utility usage, from advanced devices such as electricity meters, gas meters, and water meters, through a network on request or a pre-defined schedule. This infrastructure includes hardware, software, communications, customer associated systems and meter data management software. The infrastructure collects and distributes information to customers, suppliers, utility companies and service providers. This enables these businesses to either participate in, or provide, demand response solutions, products and services. Customers may alter energy usage patterns from normal consumption patterns in response to demand pricing. This improves system load and reliability.

SUMMARY OF THE INVENTION

A method and system provide local communication within a mesh network without associating with the mesh network. Instead of retrieving a short addresses assigned by a mesh gate to a meter, an off-network device may broadcast a query to locate all meters within radio range and await responses. For example, the query may include filtering criteria, so that only relevant meters may respond.

Each meter may respond with its network address (long address). After the off-network device identifies a meter to communicate with, future communications may be conducted with the meter's long address. This eliminates the need to first associate with the mesh network before communicating with the meter.

In another aspect, there is provided a method, including: responsive to receiving a packet, parsing a packet header; computing a response to the packet; responsive to determining the packet includes a short address addressee, transmitting the response via a mesh network; and responsive to determining the packet includes a long address addressee, transmitting the response via a point-to-point protocol.

In another aspect, there is provided a method, including: broadcasting a query to a set of mesh devices; receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device; selecting a mesh device from a set of mesh devices; and transmitting a packet to the selected mesh device using the associated mesh device long address.

In another aspect, there is provided a mesh device, including: a radio configured to communicate with a mesh network and an off-network device; a short address network stack configured to communicate over the mesh network; and a long address network stack configured to communicate directly with the off-network device.

In another aspect, there is provided an apparatus, including: a receiver receiving a packet that includes a packet header; a packet parser unit that parses the packet header in response to receiving the packet and packet header; a processing logic for computing a response to the packet; an address type identification unit that identifies the packet as including a short address addressee or a long address addressee; at least one transmitter unit that transmits the computed packet response: (i) via a mesh network in responsive to determining the packet includes a short address addressee, and (ii) via a point-to-point protocol in response to determining the packet includes a long address addressee.

In another aspect, there is provided an apparatus, including: a broadcast transmitter broadcasting a query to a set of mesh devices; a receiver receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device; a selection logic unit selecting a mesh device from a set of mesh devices; and a packet transmitter transmitting a packet to the selected mesh device using the associated mesh device long address.

In another aspect, there is provided a method for providing point-to-point communications between an off-network device and a selected mesh device, including: broadcasting a query to a set of mesh devices within radio range by the off-network device; receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device; selecting the selected mesh device from the set of mesh devices within radio range; transmitting a packet to the selected mesh device using the associated mesh device long address; responsive to receiving a packet at the selected mesh device, parsing a packet header; computing a response to the packet by the selected mesh device; and responsive to determining the packet includes a long address addressee, transmitting the response to the off-network device via a point-to-point protocol.

In another aspect, there is provided a system for providing point-to-point communications between an off-network device and a selected mesh device, including: a broadcast transmitter broadcasting a query to a set of mesh devices within radio range by the off-network device; a first receiver receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device; a selection logic unit selecting the selected mesh device from the set of mesh devices within radio range; a packet transmitter transmitting a packet to the selected mesh device using the associated mesh device long address; a second receiver receiving a packet that includes a packet header; a packet parser unit that parses the packet header in response to receiving the packet and packet header; a processing logic for computing a response to the packet; an address type identification unit that identifies the packet as including a short address addressee or a long address addressee; at least one packet response transmitter unit that transmits the computed packet response: (i) via a mesh network in responsive to determining the packet includes a short address addressee, and (ii) via a point-to-point protocol in response to determining the packet includes a long address addressee.

In another aspect, there is provided a computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method comprising: responsive to receiving a packet, parsing a packet header; computing a response to the packet; responsive to determining the packet includes a short address addressee, transmitting the response via a mesh network; and responsive to determining the packet includes a long address addressee, transmitting the response via a point-to-point protocol.

In another aspect, there is provided a computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method comprising: broadcasting a query to a set of mesh devices; receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device; selecting a mesh device from a set of mesh devices; and transmitting a packet to the selected mesh device using the associated mesh device long address.

In another aspect, there is provided a computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method for providing point-to-point communications between an off-network device and a selected mesh device, comprising: broadcasting a query to a set of mesh devices within radio range by the off-network device; receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device; selecting the selected mesh device from the set of mesh devices within radio range; transmitting a packet to the selected mesh device using the associated mesh device long address; responsive to receiving a packet at the selected mesh device, parsing a packet header; computing a response to the packet by the selected mesh device; and responsive to determining the packet includes a long address addressee, transmitting the response to the off-network device via a point-to-point protocol.

Other aspects and features will be apparent from the included description, drawings, and accompanying claims.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system for providing communications in an AMI system.

FIG. 2A illustrates an example meter for use within a mesh network.

FIG. 2B illustrates an example mesh gate for use within a mesh network.

FIG. 3A illustrates an example short address network stack for use within a mesh radio.

FIG. 3B illustrates an example long address network stack for use within a mesh radio.

FIG. 4A illustrates an example procedure for replying to a long address communication.

FIG. 4B illustrates an example procedure for sending a long address communication.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates an example system for providing communications in an AMI system. A mesh network A 100 may include a mesh gate A 102 and a plurality of meters: meters A 104, B 106, C 108, D 110, E 112, and F 114. A mesh gate may also be referred to as a NAN-WAN gate or an access point. The mesh gate A 102 may communicate with a server 118 over a wide area network (WAN) 116. Optionally, a mesh gate B 120 and a mesh network B 122 may also communicate with the server 118 over the Wide Area Network (WAN) 116.

Optionally, a mesh gate C 124 and a mesh network C 126 may also communicate with the server 118 over the WAN 116. An unassociated device 130 may seek to communicate with the server 118.

In the example of FIG. 1, the mesh network A 100 may include a plurality of mesh gates and mesh devices (such as meters) which cover a geographical area. The meters may include utility sensors and be part of an AMI system and communicate with the mesh gates over the mesh network. For example, the AMI system may monitor utilities usage, such as gas, water, or electricity usage and usage patterns. Alternative mesh devices include thermostats, user displays, and other components for monitoring utilities.

A mesh device can be any device configured to participate as a node within a mesh network. An example mesh device is a mesh repeater, which can be a wired device configured to retransmit received mesh transmissions. This extends the range of a mesh network and provides mesh network functionality to mesh devices that enter sleep cycles.

In the example of FIG. 1, the mesh gate A 102 may provide a gateway between the mesh network and a server. The mesh gate A 102 may include a mesh radio to communicate with the mesh network and a WAN communication interface to communicate with a WAN.

In the example of FIG. 1, the mesh gate A 102 may aggregate information from mesh devices, e.g., meters, repeaters, and gates, within the mesh network and transmit the information to the server. While only one mesh gate is depicted, any number of mesh gates may be deployed within the mesh network, for example, to improve transmission bandwidth to the server and provide redundancy in the mesh network. A typical system will include a plurality of mesh gates within the mesh network. In a non-limiting embodiment for an urban or metropolitan geographical area, there may be between 1 and 100 mesh gates, but this is not a limitation of the invention. In one embodiment, each mesh gate supports approximately 400 meters, depending on system requirements, wireless reception conditions, available bandwidth, and other considerations. It will be appreciated that it is preferable to limit meter usage of bandwidth to allow for future upgrades.

The mesh gate may also be known as a collector, a concentrator, or an access point.

In the example of FIG. 1, the meters A 104, B 106, C 108, D 110, E 112, and F 114 may each be a mesh device associated with the mesh network through direct or indirect communications with the mesh gate. Each meter may forward or relay transmissions from other meters within the mesh network towards the mesh gate. While only six meters are depicted, any number of meters may be deployed to cover any number of utility lines or locations within the mesh network.

In the example of FIG. 1, as depicted, only meters A 104 and D 110 are in direct communications with mesh gate A 102. However, meters B 106, E 112 and F 114 can all reach mesh gate A 102 through meter D 110. Similarly, meter C 108 can reach mesh gate A 102 through meter E 112 and meter D 110.

In the example of FIG. 1, the WAN 116 may be a communication medium capable of transmitting digital information. For example, the WAN 116 may be the Internet, a cellular network, a private network, a phone line configured to carry a dial-up connection, an Ethernet network, or any other network. The WAN 116 can support TCP/IP or another protocol, and is therefore technology agnostic.

In the example of FIG. 1, the server 118 may be a computing device configured to receive information, such as meter readings, from a plurality of mesh networks and meters. The server 118 may also be configured to transmit instructions and information to the mesh networks and corresponding mesh devices, i.e., mesh gates and meters.

In an alternative embodiment, any number of servers may be deployed in the AMI system. For example, servers may be distributed by geographical location for shorter communication distances and latency times. Redundant servers may provide backup and failover capabilities in the AMI system. The server 118 may also be known as a “head end server” or “head end.”

In the example of FIG. 1, the optional mesh gates B 120 and C 124 may be similar to mesh gate A 102, discussed above. Each mesh gate may be associated with a mesh network, similar to the mesh network A 102. For example, mesh gate B 120 may be associated with mesh network B 122 and mesh gate C 124 may be associated with mesh network C 126. Each mesh network may include a plurality of meters (not depicted).

In the example of FIG. 1, each mesh network may include meters covering a geographical area, such as a premise, a residential building, an apartment building, or a residential block. Alternatively, the mesh network may include a utilities network and be configured to measure utilities flow at each sensor. Each mesh gate communicates with the server over the WAN, and thus the server may receive information from and control a large number of meters or mesh devices within a plurality of mesh networks. Mesh devices may be located wherever they are needed, without the necessity of providing wired communications with the server.

In the example of FIG. 1, the off-network device 130 may be a mobile test device used by a user, for example, service personnel maintaining mesh devices. The off-network device 130 may be configured to broadcast a query for all nearby mesh devices responsive to a user instruction. The query may include filtering criteria, such as limiting responding mesh devices to only gas meters. Every qualifying mesh device that receives the query may reply with an identifier and a network address.

In the example of FIG. 1, in operation, an AMI system may facilitate communications between the system components. A mesh network A 100 may include a plurality of meters. An off-network device 130 may be unassociated with the mesh network A 100 and communicate with at least one of the meters. The off-network device 130 may display available mesh devices to a user, and, responsive to user input, select a meter to communicate with. For example, the off-network device 130 may select meter F 114. Without associating with the mesh network A 100 through the mesh gate A 102, the off-network device 130 may broadcast a communication addressed with the meter F's network address. Any recipient of the broadcast will check the addressee and ignore the message unless the recipient is meter F 114 having the matching address.

In an alternative, a meter may reply to the off-network device's broadcast with not only its own identifier and network address, but also with information about neighbors reachable from the meter. The off-network device may therefore initiate point-to-point communication with any meter in a mesh network without associating with the mesh network or the mesh gate and without corresponding directly with the meter.

FIG. 2A illustrates an example meter for use within a mesh network. A meter 200 may include a radio 202, a communication card 204, a metering sensor 206, and a battery or other power or energy storage device or source 208. The radio 202 may include a memory 210, a processor 212, a transceiver 214, and a microcontroller unit (MCU) 216.

In the example of FIG. 2A, the meter 200 may be a mesh device communicating with a mesh gate and other mesh devices over a mesh network. For example, the meter 200 may be a gas, water or electricity meter installed in a residential building or other location to monitor utilities usage. The meter 200 may also control access to utilities on server instructions, for example, by reducing or stopping the flow of gas, water or electricity.

In the example of FIG. 2A, the radio 202 may be a mesh radio configured to communicate with a mesh network. The radio 202 may transmit, receive, and forward messages to the mesh network. Any meter within the mesh network may thus communicate with any other meter or mesh gate by communicating with its neighbor and requesting a message be forwarded. The radio 202 may also communicate with an off-network device not associated with the mesh network.

In the example of FIG. 2A, the communication card 204 may interface between the radio and the sensor 206. Sensor readings or other data may be converted by the communication card 204 to radio signals for transmission over the radio 202. The communication card 204 may include encryption/decryption functionality or other security measures to protect the transmitted data. The communication card 204 may also decode instructions received from the server or other communicating devices.

In the example of FIG. 2A, the metering sensor 206 may be a gas, water, or electricity meter sensor, or another sensor. For example, analog or digital flow sensors may be used to measure a quantity of water or gas flowing into a residence or building. Alternatively, the sensor 206 may be an electricity meter configured to measure a quantity of electricity flowing over a power line.

In the example of FIG. 2A, the battery or other energy storage device 208 may be configured to independently power the meter during a power outage. For example, the battery or other energy storage device 208 may be a large capacitor storing electricity to power the meter for at least five minutes after a power outage. Small, compact but high capacity capacitors known as super capacitors are known in the art and may advantageously be used. One exemplary super capacitor is the SESSCAP 50f2.7v18×30 mm capacitor. Alternative battery technologies may be used, for example, galvanic cells, electrolytic cells, fuel cells, flow cells, and voltaic cells.

In the example of FIG. 2A, each component may be modular and configured for easy removal and replacement. This modularity facilitates component upgrading over a lifetime of the meter as new functionality is developed and deployed in the AMI system.

In the example of FIG. 2A, the memory 210 may store instructions and run-time variables for execution. For example, the memory 210 may include both volatile and non-volatile memory. The memory 210 may also store a history of sensor readings from the metering sensor 206 and an incoming queue of server instructions.

In the example of FIG. 2A, the processor 212 may execute instructions, for example, stored in the memory. Instructions stored in memory 210 may be ordinary instructions, for example, provided at time of meter installation, or special instructions received from the server during run time.

In the example of FIG. 2A, the transceiver 214 may transmit and receive wireless signals to a mesh network. The transceiver 214 may be configured to transmit sensor readings and status updates under control of the processor. The transceiver 214 may receive server instructions from a server, which are communicated to the memory and the processor.

In the example of FIG. 2A, the MCU 216 can execute firmware or software required by the meter 200. The firmware or software can be installed at manufacture or via a mesh network over the radio 202.

In one embodiment, any number of MCUs or CPUs or other processing logic can exist in the meter 200. For example, two MCUs can be installed, a first MCU for executing firmware handling communication protocols, and a second MCU for handling applications.

In the example of FIG. 2A, meters may be located in geographically dispersed locations within an AMI system. For example, a meter may be located near a gas line, an electric line, or a water line entering a building or premise to monitor a quantity of gas, electricity, or water flowing through the line. The meter may communicate with other meters and mesh gates through a mesh network. The meter may transmit meter readings and receive instructions via the mesh network.

In the example of FIG. 2A, in operation, the meter 200 may communicate over a mesh network and directly with an off-network device via the radio 202. The communication card 204 may interface between the metering sensor 206 and the radio 202. For example, sensor readings may be transmitted to and instructions received from a server.

In an alternative embodiment, mesh devices may be similar to meters except the metering sensor is replaced by whatever component is necessary to perform the mesh device's function. For example, a user display may include an output screen and a thermostat may include a dial for receiving user input and an analog/digital converter to produce an input signal.

It will be appreciated that a mesh device and a mesh gate can share the architecture of meter 200. The radio 202 and the MCU 216 provide the hardware necessary, and the MCU 216 executes any necessary firmware or software.

FIG. 2B illustrates an example mobile device 230 for use within a mesh network. The mobile device 230 may include a mesh radio 232, a wide area network (WAN) interface 234, a battery 236, and a processor 238. The mesh radio 232 may include a memory 242, a processor 244, and a transceiver 246.

In the example of FIG. 2B, the mesh radio 232 may be a mesh radio configured to communicate with meters over a mesh network. The radio 232 may transmit, receive, and forward messages to the mesh network.

In the example of FIG. 2B, the WAN interface 234 may communicate with a server over a WAN. For example, the WAN may be a cellular network, a private network, a dial up connection, or any other network. The WAN interface 234 may include encryption/decryption functionality or other security measures to protect data being transmitted to and from the server.

In the example of FIG. 2B, the battery or other energy storage device 236 may be configured to independently power the mesh gate during a power outage. For example, the battery 236 may be a large capacitor (such as a so called super capacitor) storing electricity to power the mesh gate for at least five minutes after a power outage.

In the example of FIG. 2B, the processor 238 may control the mesh radio 232 and the WAN interface. Meter information received from the meters over the mesh radio may be compiled or assembled into composite messages for transmission to the server. Server instructions may be received from the WAN interface and transmitted to meters in the mesh network for execution. Server instructions may also be received from the WAN interface for execution by the processor.

In the example of FIG. 2B, the mesh radio, WAN interface, battery or energy storage device, and processor each may be modular and configured for easy removal and replacement. This modularity facilitates component upgrading over a lifetime of the mesh gate.

In the example of FIG. 2B, the memory 242 may store instructions and run-time variables of the mesh radio. For example, the memory 242 may include both volatile and non-volatile memory. The memory 242 may also store a history of meter communications and a queue of incoming server instructions. For example, meter communications may include past sensor readings and status updates.

In the example of FIG. 2B, the processor 244 may execute instructions stored in the memory. Stored instructions may be ordinary instructions, for example, provided at time of mesh gate installation, or special instructions received from the server during run-time.

In the example of FIG. 2B, the transceiver 246 may transmit and receive wireless signals to a mesh network. The transceiver 246 may be configured to receive sensor readings and status updates from a plurality of meters in the mesh network. The transceiver 246 may also receive server instructions, which are communicated to the memory and the processor.

In the example of FIG. 2B, in operation, the mesh gate may interface between a mesh network and a server. The mesh gate may communicate with meters in the mesh network and communicate with the server over a WAN network. By acting as a gateway, the mesh gate forwards information and instructions between the meters in its mesh network and the server.

FIG. 3A illustrates an example short address network stack for use within a mesh radio 300. The mesh radio can be a radio illustrated in FIG. 2A or a mesh radio 232 illustrated in FIG. 2B. The application process 302 may communicate with a network stack consisting of an application layer 304, a transport layer 306, a network layer 308, a data link layer 310, and a physical layer 312.

In the example of FIG. 3A, the mesh radio 300 may be a mesh radio installed in a mesh gate, a mesh device or an off-network device. For example, the mesh radio 300 may be a component in a meter, a mesh gate, or any other mesh device configured to participate in a mesh network or communicate with other mesh devices. The mesh radio 300 may be configured to transmit wireless signals over a predetermined or dynamically determined frequency to other radios.

In the example of FIG. 3A, the application process 302 may be an executing application that requires information to be communicated over the network stack. For example, the application process 302 may be software supporting an AMI system, such as software executing on an electricity meter or a mesh gate.

In the example of FIG. 3A, the application layer 304 interfaces directly with and performs common application services for application processes. Functionality includes semantic conversion between associated application processes. For example, the application layer may be implemented as ANSI C12.12/22.

In the example of FIG. 3A, the transport layer 306 responds to service requests from the application layer and issues service requests to the Internet layer. It delivers data to the appropriate application on the host computers. For example, the layer may be implemented as TCP (Transmission Control Protocol), and UDP (User Datagram Protocol).

In the example of FIG. 3A, the network layer 308 is responsible for end-to-end (source-to-destination) packet delivery. The layer's functionality includes transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service, and error control functions. Data will be transmitted from its source to its destination, even if the transmission path involves multiple hops. For example, the network layer 308 may translate a short address into a network address.

In the example of FIG. 3A, the data link layer 310 transfers data between adjacent network nodes in a network, wherein the data is in the form of packets. The layer provides functionality including transferring data between network entities and error correction/detection. For example, the layer may be implemented as IEEE 802.15.4.

In the example of FIG. 3A, the physical layer 312 may be the most basic network layer, transmitting bits over a data link connecting network nodes. No packet headers or trailers are included. The bit stream may be grouped into code words or symbols and converted to a physical signal, which is transmitted over a transmission medium, such as radio waves. The physical layer provides an electrical, mechanical, and procedural interface to the transmission medium. For example, the layer may be implemented as IEEE 802.15.4.

In the example of FIG. 3A, in operation, the network stack provides different levels of abstraction for programmers within an AMI system. Abstraction reduces a concept to only information which is relevant for a particular purpose. Thus, each level of the network stack may assume the functionality below it on the stack is implemented. This facilitates programming features and functionality for the AMI system. The illustrated network stack may facilitate intra-mesh network communication by utilizing a short address to identify addressees.

FIG. 3B illustrates an example long address network stack for use within a mesh radio 350. The long address stack must be used when passing information to/from devices outside of the mesh network; whereas for communications between nodes within the mesh network, a short address stack is used for efficiency. The application process 352 may communicate with an application layer 354, a transport and network layer 356, a data link layer 358 and a physical layer 360.

In the example of FIG. 3B, the radio 350 may be a mesh radio installed in a mesh gate, a mesh device or an off-network device. For example, the radio 350 may be a component in a meter, a mesh gate, or any other mesh device configured to participate in a mesh network or communicate with other mesh devices. The radio 350 may be configured to transmit wireless signals over a predetermined or dynamically determined frequency to other radios.

In the example of FIG. 3B, the application process 352 may be an executing application that requires information to be communicated over the network stack. For example, the application process 352 may be software supporting an AMI system, such as software executing on an electricity meter or a mesh gate.

In the example of FIG. 3B, the application layer 354 interfaces directly with and performs common application services for application processes. Functionality includes semantic conversion between associated application processes. For example, the application layer may be implemented as ANSI C12.12/22.

In the example of FIG. 3B, the transport and network layer 356 responds to service requests from the application layer and issues service requests to the Internet layer. It delivers data to the appropriate application on the host computers. For example, the layer may be implemented as TCP (Transmission Control Protocol), and UDP (User Datagram Protocol). The network portion of the layer 356 may be responsible for end to end (source to destination) packet delivery. The layer's functionality includes transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service, and error control functions. Data will be transmitted from its source to its destination, even if the transmission path involves multiple hops. Further details and embodiments describing the transport and network layer are found in at least U.S. patent application Ser. No. ______ (Attorney Docket No. TR0003-US) filed Nov. ______, 2008 and entitled “Efficient And Compact Transport Layer And Model For An Advanced Metering Infrastructure (AMI) Network,” which is incorporated herein by reference in its entirety.

In the example of FIG. 3B, the data link layer 358 transfers data between adjacent network nodes in a network, wherein the data is in the form of packets. The layer provides functionality including transferring data between network entities and error correction/detection. For example, the layer may be implemented as IEEE 802.15.4.

In the example of FIG. 3B, the physical layer 360 may be the most basic network layer, transmitting bits over a data link connecting network nodes. No packet headers or trailers are included. The bit stream may be grouped into code words or symbols and converted to a physical signal, which is transmitted over a transmission medium, such as radio waves. The physical layer provides an electrical, mechanical, and procedural interface to the transmission medium. For example, the layer may be implemented as IEEE 802.15.4.

In the example of FIG. 3B, in operation, the network stack provides different levels of abstraction for programmers within an AMI system. Abstraction reduces a concept to only information which is relevant for a particular purpose. Thus, each level of the network stack may assume the functionality below it on the stack is implemented. This facilitates programming features and functionality for the AMI system. The illustrated network stack may facilitate intra-mesh network communication by utilizing a short address to identify addressees.

In the example of FIG. 3B, the same hardware may be used as in FIG. 3A. A long address transmission may be processed by a combined transport and network layer, as the functionality for mesh addressing is not required. In an alternative, a short address transmission may be processed by a special network layer, which determines an appropriate long address from the parsed short address. The message is then transmitted with the long address.

FIG. 4A illustrates an example procedure 400 for replying to a long address communication. The procedure may execute on a mesh device, such as a meter. The mesh device may be associated with a mesh network and communicate with other devices associated with the mesh network. The mesh device may also be configured to respond to off-network devices not associated with the mesh network. An off-network device may select the meter and use a long address for bilateral communication with the mesh device, without associating with the mesh device.

In the example of FIG. 4A, in 402, the mesh device may optionally receive a broadcasted query from an off-network device. The query may include an off-network device identifier and a request for any mesh devices within radio range to respond with a mesh device long address. Optionally, the query may also include filter criteria indicating the mesh devices that should respond. For example, the filter criteria may indicate only a type of mesh device, such as meters, user displays, or thermostats are to respond. And by way of further example, the filter criteria may indicate that only a mesh device with a specified mesh device identifier, such as a utility meter number or other serial number, is to respond.

In one example, the broadcasted query can be a request to conduct a range test. The range test can measure a signal strength of a response message. The range test can be conducted between the off-network device and the mesh device. Alternatively, the request can instruct the mesh device to conduct the range test with another mesh device.

The range test can initiate a range test response in a recipient. A signal strength of the range test response is recorded and measured to determine a signal strength. A signal quality can also be measured. If no range test response is received or if the signal quality is too low, the recipient mesh device may be flagged as out of range.

In the example of FIG. 4A, the off-network device may be a mobile device used by service personnel to service mesh devices within the AMI system. Such a mobile device may be within proximity of the mesh devices to be serviced during a service call and interact with service personnel to provide information on the mesh devices.

In the example of FIG. 4A, mesh devices may need to be installed, maintained, repaired, or otherwise serviced. It may be cumbersome for the mobile device to associate with the mesh network for every mesh device to be serviced.

In the example of FIG. 4A, the mesh device may proceed to 404 if a broadcasted query is received.

In the example of FIG. 4A, in 404, the mesh device may optionally check whether filter criteria are satisfied. For example, filter criteria may optionally be received along with the broadcasted query. The mesh device may perform a comparison of its characteristics against the received filter criteria.

In the example of FIG. 4A, the mesh device may proceed to 406 if the filter criteria are satisfied.

In the example of FIG. 4A, in 406, the mesh device may optionally transmit a mesh device identifier and a mesh device long address to the off-network device. When the mesh device determines it is appropriate to respond to a broadcasted query, it will reply with information required by the off-network device to initiate local communication. Other data may also be transmitted, for example, a mesh device characteristic or other information.

In the example of FIG. 4A, in 410, the mesh device may receive a packet from the off-network device. For example, a packet may be received from within the mesh network or from an off-network device. The packet may be transmitted over a predetermined or dynamically determined frequency used by the mesh network.

In the example of FIG. 4A, if a packet has been received, the mesh device may proceed to step 412 where the packet is processed. If no packet has been received, the mesh device may remain at 410.

In the example of FIG. 4A, the received packet may be a local communication not received via the mesh network. For example, the received packet may be received in direct communication with an off-network device. The off-network device may transmit maintenance requests to the mesh device. The maintenance request may be an installation of the mesh device, maintenance of the mesh device, a testing of the mesh device, or a walk-by reading of the mesh device.

In the example of FIG. 4A, in process or step 412, the mesh device may parse a packet header from the received packet received. The packet header may indicate whether a short address or long address was used to transmit the packet to the mesh device. For example, the packet header may have one of two predetermined sizes. If the packet header is of a first size, it may have been transmitted with a short address. If the packet header is of a second size, it may have been transmitted with a long address.

In the example of FIG. 4A, in process or step 414, the mesh device may compute a response to the received packet. For example, the packet may request a status, sensor reading, stored value, or other information from the mesh device. The mesh device may retrieve or compute the necessary response. For example, the packet may contain instructions to be executed on the mesh device. The mesh device may execute the instructions and reply with an error code or execution completed message.

In an alternative, no response may be required to the received packet. If no response is required, the procedure may end.

In the example of FIG. 4A, in process or step 416, the mesh device may check whether the received packet has a short addressee. A short addressee may be used for communications within the mesh network, for example, from a mesh device to a mesh gate or from a first mesh device to a second mesh device. For example, the packet header size may be checked. In an alternative, the packet may be parsed and a flag status may be extracted.

In the example of FIG. 4A, if the packet has a short addressee, the packet was transmitted over the mesh network. The mesh device proceeds to process or step 420. If the packet does not have a short addressee, the mesh device proceeds to process or step 418.

In the example of FIG. 4A, in process or step 418, the mesh device may check whether the received packet has a long addressee. A long addressee may be used for direct communications with the off-network device not associated with the mesh network, and therefore without access to the short address of the mesh device. For example, the packet header size may be checked. In an alternative, the packet may be parsed and a flag status may be extracted.

In the example of FIG. 4A, if the packet has a long addressee, the packet was transmitted from an off-network device. The mesh device proceeds to process or step 422.

In the example of FIG. 4A, in process or step 420, the mesh device may transmit the response via the mesh network. For example, the mesh device may include a mesh network stack which transmits messages via the mesh network.

In the example of FIG. 4A, in process or step 422, the mesh device may transmit the response via a point-to-point protocol. For example, the mesh device may include a local communication stack which transmits messages via direct communication.

In the example of FIG. 4A, a mesh device may be configured to communicate both over a mesh network and directly with a non-network device. For example, mesh network communication may support a short address, lowering overhead of inter-mesh network communications. For example, the non-network device may not be associated with the mesh network, and therefore use the mesh device's long address.

In an alternative, it will be appreciated that the mesh device may function as a proxy for a recipient mesh device. The recipient mesh device may be out of radio range of the non-network device but be a target for communication. The proxy mesh device may reply to the non-network device's broadcasted query with mesh devices it can reach, including the recipient mesh device. The non-network device may then communicate with the proxy mesh device using a long address, while the proxy mesh device forwards the communications to the recipient mesh device.

FIG. 4B illustrates an example procedure 450 for sending a long address communication. The procedure may execute on an off-network device, such as a mobile diagnostic device used by service personnel when servicing mesh devices of an AMI system. The mesh device may be associated with a mesh network and communicate with other devices associated with the mesh network. The mesh device may also be configured to respond to off-network devices not associated with the mesh network. An off-network device may select the meter and use a long address for bilateral communication with the mesh device, without associating with the mesh device.

In the example of FIG. 4B, secure communications can be established from the off-network device the mesh device. A key or other secure identifier is transmitted from the off-network device to the mesh device. In one example embodiment, the mesh device forwards the key to the server for authentication. In this example embodiment, the server maintains a record of known valid keys of off-network devices.

In another example embodiment, the mesh device authenticates the key by maintaining a record of known valid keys of off-network devices.

In the example of FIG. 4B, the non-network device may broadcast a query to any mesh devices within radio range in 452. For example, the non-network device may receive a request from a user, such as a service personnel, to identify all nearby and active mesh devices. The broadcasted query may be transmitted on a predetermined or dynamically determined frequency, for example, the frequency of the mesh network. The broadcasted query may further be transmitted in a mesh network protocol. In this example, the non-network device and the mesh devices may require a mesh radio configured to transmit on the appropriate frequency and using the appropriate protocol. No additional hardware, such as additional radios or processing components, may be required.

In the example of FIG. 4B, in process or step 454 the non-network device may optionally broadcast filter criteria along with the query. For example, the user may specify the mesh devices to respond. The user may specify only certain types of mesh devices may respond, such as gas meters, thermostats, user input devices, or other types of mesh devices. For example, the user may specify only mesh devices associated with a specified mesh network may respond. Any combination of filter criteria may be broadcasted.

In the example of FIG. 4B, the user may specify only the mesh device matching a specified mesh device identifier is to respond. For example, mesh device identifiers may be printed on an external surface of the mesh device. Thus, the user may service a specific mesh device in proximity to the non-network device.

In the example of FIG. 4B, in process or step 456 the non-network device may test whether a response has been received. For example, the non-network device may wait for a time interval during which it awaits responses from nearby mesh devices. If at least one response is received, the non-network device may proceed to 458. If no response is received, the non-network device may wait at 456. If a time-out period has elapsed, the non-network device may stop waiting for a response.

In the example of FIG. 4B, if no responses are received, an error message may be displayed to the user. There may be no mesh devices within radio range. There may be no mesh devices within radio that satisfy the filter criteria. There may be a transmission error.

In the example of FIG. 4B, each response may include a mesh device identifier and a mesh device long address. Optionally, additional information may also be included with the response, such as a mesh device status.

In the example of FIG. 4B, in process or step 458 the non-network device may select a mesh device for direct communication. The mesh device may be selected from a set of mesh devices that responded to the broadcasted query.

In the example of FIG. 4B, in 460 the non-network device may transmit a packet to the mesh device. The selected mesh device may be selected above. The package may be transmitted using a local communication protocol, that is, to a mesh device in direct radio contact with the off-network device.

In the example of FIG. 4B, the packet may be a maintenance request. For example, the maintenance request may be used during at least one of: an installation of the mesh device, maintenance of the mesh device, testing of the mesh device, or a walk-by reading of the mesh device. The packet may be instructions to be executed by the mesh device.

In the example of FIG. 4B, in process or step 462 the non-network device may optionally receive a response from the mesh device. For example, a response may be required to be responsive to the packet transmitted to the selected mesh device. If the packet transmitted was instructions to be executed by the mesh device, a response may be an error code or an indicator that the instructions were successfully executed.

Although the above embodiments have been discussed with reference to specific example embodiments, it will be evident that the various modification, combinations and changes can be made to these embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense. The foregoing specification provides a description with reference to specific exemplary embodiments. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method, comprising:

responsive to receiving a packet, parsing a packet header;

computing a response to the packet;

responsive to determining the packet includes a short address addressee, transmitting the response via a mesh network; and

responsive to determining the packet includes a long address addressee, transmitting the response via a point-to-point protocol.

2. The method of claim 1, further comprising:

associating with a mesh network within radio range.

3. The method of claim 1, further comprising:

determining the packet is a maintenance request transmitted by an off-network device.

4. The method of claim 3, wherein the maintenance request is used during at least one of: an installation of a mesh device, a maintenance of the mesh device, a testing of the mesh device, and a walk-by or drive-by reading of the mesh device.

5. The method of claim 1, further comprising:

determining the packet is a local communication not received via the mesh network.

6. The method of claim 1, further comprising:

responsive to receiving a broadcasted query, replying with a mesh device identifier and a mesh device long address.

7. The method of claim 6, further comprising:

verifying a filter criteria is satisfied before replying, wherein the filter criteria is received with the broadcasted query.

8. The method of claim 1, further comprising:

determining the packet has a short address addressee by examining a size of the header.

9. The method of claim 1, further comprising:

processing the packet on a mesh network stack if the packet has a short address addressee; and

processing the packet on a local communication stack if the packet has a long address addressee.

10. A method, comprising:

broadcasting a query to a set of mesh devices;

receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device;

selecting a mesh device from a set of mesh devices; and

transmitting a packet to the selected mesh device using the associated mesh device long address.

11. The method of claim 10, wherein the packet is a maintenance request.

12. The method of claim 11, wherein the maintenance request is used during at least one of: an installation of a mesh device, a maintenance of the mesh device, a testing of the mesh device, and a walk-by or drive-by reading of the mesh device.

13. The method of claim 10, further comprising:

receiving a mesh device identifier associated with each mesh device responsive to the broadcasted query.

14. The method of claim 10, further comprising:

broadcasting a filter criteria indicating desired mesh devices along with the broadcasted query.

15. The method of claim 10, further comprising:

receiving a response responsive to the transmitted packet.

16. The method of claim 10, wherein:

the broadcasting of a query to a set of mesh devices is to mesh devices within radio range;

the receiving of at least one response from the set of mesh devices is a receiving of at least one response from the set of mesh devices within radio range;

and the selecting of a mesh device from a set of mesh devices is the selecting of a mesh device from a set of mesh devices within radio range.

17. A mesh device, comprising:

a radio configured to communicate with a mesh network and an off-network device;

a short address network stack configured to communicate over the mesh network; and

a long address network stack configured to communicate directly with the off-network device.

18. The mesh device of claim 17, the mesh device configured to associate with a mesh network within radio range.

19. The mesh device of claim 17, wherein the radio is further configured to receive a packet and the mesh device is configured to:

responsive to determining the packet includes a short address addressee, transmitting the response via the short address network stack; and

responsive to determining the packet includes a long address addressee, transmitting the response via a long address network stack.

20. The mesh device of claim 19, wherein the packet is a maintenance request transmitted by an off-network device.

21. The mesh device of 20, wherein the maintenance request is used during at least one of: an installation of the mesh device, a maintenance of the mesh device, a testing of the mesh device, and a walk-by reading of the mesh device.

22. An apparatus, comprising:

a receiver receiving a packet that includes a packet header;

a packet parser unit that parses the packet header in response to receiving the packet and packet header;

a processing logic for computing a response to the packet;

an address type identification unit that identifies the packet as including a short address addressee or a long address addressee;

at least one transmitter unit that transmits the computed packet response: (i) via a mesh network in response to determining the packet includes a short address addressee, and (ii) via a point-to-point protocol in response to determining the packet includes a long address addressee.

23. The apparatus of claim 22, further comprising:

means for associating with a mesh network within radio range.

24. The apparatus of claim 22, further comprising:

means for determining the packet is a maintenance request transmitted by an off-network device.

25. The apparatus of claim 24, wherein the maintenance request is used during at least one of: an installation of a mesh device, a maintenance of the mesh device, a testing of the mesh device, and a walk-by or drive-by reading of the mesh device.

26. The apparatus of claim 22, further comprising:

means for determining the packet is a local communication not received via the mesh network.

27. The apparatus of claim 22, further comprising:

means for replying with a mesh device identifier and a mesh device long address in response to receiving a broadcasted query.

28. The apparatus of claim 27, further comprising:

means for verifying a filter criteria is satisfied before replying, wherein the filter criteria is received with the broadcasted query.

29. The apparatus of claim 22, further comprising:

means for determining the packet has a short address addressee by examining a size of the header.

30. The apparatus of claim 22, further comprising:

processing logic configured to:

process the packet on a mesh network stack if the packet has a short address addressee; and

process the packet on a local communication stack if the packet has a long address addressee.

31. An apparatus, comprising:

a broadcast transmitter broadcasting a query to a set of mesh devices;

a receiver receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device;

a selection logic unit selecting a mesh device from a set of mesh devices; and

a packet transmitter transmitting a packet to the selected mesh device using the associated mesh device long address.

32. The apparatus of claim 31, wherein the broadcast transmitter and the packet transmitter are the same transmitter.

33. The apparatus of claim 31, wherein the broadcast transmitter and the packet transmitter are different transmitters.

34. The apparatus of claim 31, wherein the packet comprises a maintenance request.

35. The apparatus of claim 34, wherein the maintenance request is used during at least one of: an installation of a mesh device, a maintenance of the mesh device, a testing of the mesh device, and a walk-by or drive-by reading of the mesh device.

36. The apparatus of claim 31, wherein:

the receiver is adapted for receiving a mesh device identifier associated with each mesh device responsive to the broadcasted query.

37. The apparatus of claim 31, wherein:

the broadcast transmitter is adapted for broadcasting a filter criteria indicating desired mesh devices along with the broadcasted query.

38. The apparatus of claim 31, wherein:

the receiver is adapted for receiving a response responsive to the transmitted packet.

39. The apparatus of claim 31, wherein:

the broadcasting of a query to a set of mesh devices is to mesh devices within the broadcast transmitter radio range;

the receiving of at least one response from the set of mesh devices is a receiving of at least one response from the set of mesh devices within the receiver radio range;

and the selecting of a mesh device from a set of mesh devices is the selecting of a mesh device from a set of mesh devices within radio range.

40. A method for providing point-to-point communications between an off-network device and a selected mesh device, comprising:

broadcasting a query to a set of mesh devices within radio range by the off-network device;

receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device;

selecting the selected mesh device from the set of mesh devices within radio range;

transmitting a packet to the selected mesh device using the associated mesh device long address;

responsive to receiving a packet at the selected mesh device, parsing a packet header;

computing a response to the packet by the selected mesh device; and responsive to determining the packet includes a long address addressee, transmitting the response to the off-network device via a point-to-point protocol.

41. A system for providing point-to-point communications between an off-network device and a selected mesh device, comprising:

a broadcast transmitter broadcasting a query to a set of mesh devices within radio range by the off-network device;

a first receiver receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device;

a selection logic unit selecting the selected mesh device from the set of mesh devices within radio range;

a packet transmitter transmitting a packet to the selected mesh device using the associated mesh device long address;

a second receiver receiving a packet that includes a packet header;

a packet parser unit that parses the packet header in response to receiving the packet and packet header;

a processing logic for computing a response to the packet;

an address type identification unit that identifies the packet as including a short address addressee or a long address addressee;

at least one packet response transmitter unit that transmits the computed packet response: (i) via a mesh network in response to determining the packet includes a short address addressee, and (ii) via a point-to-point protocol in response to determining the packet includes a long address addressee.

42. A computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method comprising:

responsive to receiving a packet, parsing a packet header;

computing a response to the packet;

responsive to determining the packet includes a short address addressee, transmitting the response via a mesh network; and

responsive to determining the packet includes a long address addressee, transmitting the response via a point-to-point protocol.

43. A computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method comprising:

broadcasting a query to a set of mesh devices;

receiving at least one response from the set of mesh devices, wherein the response includes a mesh device long address associated with each mesh device;

selecting a mesh device from a set of mesh devices; and

transmitting a packet to the selected mesh device using the associated mesh device long address.

44. A computer program product stored in a computer readable media for execution in a processor and memory coupled to the processor for performing a method for providing point-to-point communications between an off-network device and a selected mesh device, comprising:

broadcasting a query to a set of mesh devices within radio range by the off-network device;

receiving at least one response from the set of mesh devices within radio range, wherein the response includes a mesh device long address associated with each mesh device;

selecting the selected mesh device from the set of mesh devices within radio range;

transmitting a packet to the selected mesh device using the associated mesh device long address;

responsive to receiving a packet at the selected mesh device, parsing a packet header;

computing a response to the packet by the selected mesh device; and responsive to determining the packet includes a long address addressee, transmitting the response to the off-network device via a point-to-point protocol.