Source: https://patents.google.com/patent/US9591525B2/en
Timestamp: 2019-08-17 20:58:12
Document Index: 609480188

Matched Legal Cases: ['Application No. 12166697', 'Application No. 2016200625', 'Application No. 2', 'Application No. 2869147', 'Application No. 2015', 'Application No. 2015', 'Application No. 2015', 'Application No. 2015', 'Application No. 2012379054', 'Application No. 12166697', 'application No. 12166697', 'application No. 12166694', 'application No. 12166697']

US9591525B2 - Efficient device handover/migration in mesh networks - Google Patents
Efficient device handover/migration in mesh networks Download PDF
US9591525B2
US9591525B2 US13/481,649 US201213481649A US9591525B2 US 9591525 B2 US9591525 B2 US 9591525B2 US 201213481649 A US201213481649 A US 201213481649A US 9591525 B2 US9591525 B2 US 9591525B2
US13/481,649
US20130294230A1 (en
2012-05-03 Priority to EP12166697 priority Critical
2012-05-03 Priority to EP12166697.8 priority
2012-05-03 Priority to EP12166697.8A priority patent/EP2661127B1/en
2012-05-07 Priority to PCT/US2012/036838 priority patent/WO2013165444A1/en
2012-05-25 Application filed by Itron Global SARL filed Critical Itron Global SARL
2012-05-25 Priority to US13/481,649 priority patent/US9591525B2/en
2012-05-29 Assigned to ITRON, INC. reassignment ITRON, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: Mani, Mehdi, Mainaud, Bastien, NGUYEN, VIET-HUNG, POPA, DANIEL, STUBER, MICHAEL T. GARRISON
2013-11-07 Publication of US20130294230A1 publication Critical patent/US20130294230A1/en
2017-03-07 Publication of US9591525B2 publication Critical patent/US9591525B2/en
A new device is deployed to an area in which a network is provided. The new device may join the network using a single handshake via a neighboring device that is a member of the network and register with a network management system managing the network. If the network is overloaded or has limited bandwidth remaining, the network may refuse to admit the new device, or if the new device is isolated, may force some devices that are members of the network to leave or migrate from the network to allow the isolated device to join the network.
This application is a continuation of PCT International Application No. PCT/US12/36838, filed on May 7, 2012, which claims priority to European Patent Application No. 12166697.8, filed May 3, 2012, and entitled “EFFICIENT DEVICE HANDOVER/MIGRATION IN MESH NETWORKS,” both of which are incorporated herein by reference.
The application describes multiple and varied implementations. The following section describes an example environment that is suitable for practicing various implementations. Next, the application describes example systems, devices, and processes for implementing device registration and device migration.
FIG. 1 is a schematic diagram of an example architecture 100 usable to implement device registration and device migration. The architecture 100 includes a plurality of nodes or devices 102-1, 102-2, 102-3, 102-4, 102-5, . . . , 102-N (collectively referred to as devices 102) communicatively coupled to each other via direct communication paths or “links.” In this example, N represents a number of devices arranged in an autonomous routing area (ARA), such as a wide area network (WAN), metropolitan area network (MAN), local area network (LAN), neighborhood area network (NAN), personal area network (PAN), or the like. While only one ARA is shown in FIG. 1, in practice, multiple ARAs may exist and may collectively define a larger network, such as an advanced metering infrastructure (AMI) network. At any given time, each individual device may be a member of a particular ARA. Over time, however, devices may migrate from one ARA to another geographically proximate or overlapping ARA based on a variety of factors, such as respective loads on the ARAs, interference, or the like.
As discussed above, the term “link” refers to a direct communication path between two devices (without passing through or being propagated by another device). The link may be over a wired or wireless communication path. Each link may represent a plurality of channels over which a device is able to transmit or receive data. Each of the plurality of channels may be defined by a frequency range which is the same or different for each of the plurality of channels. In some instances, the plurality of channels comprises radio frequency (RF) channels. The plurality of channels may comprise a control channel and multiple data channels. In some instances, the control channel is utilized for communicating one or more messages between devices to specify one of the data channels to be utilized to transfer data. Generally, transmissions on the control channel are shorter relative to transmissions on the data channels.
In this example, the devices 102 may further be configured to communicate with a central office 104 via an edge device (e.g., the device 102-4) which serves as a connection point of the ARA to a backhaul network(s) 106, such as the Internet. In one implementation, the edge device may include, but is not limited to, a cellular relay, a cellular router, an edge router, a DODAG (Destination Oriented Directed Acyclic Graph) root, a root device or node of the ARA network, etc. In this illustrated example, the device 102-1 serves as a cellular relay and/or forwarding device for other nodes in the ARA, e.g., relaying communications from the other devices 102-2-102-N of the ARA to and from the central office 104 via the network(s) 106.
In one implementation, some or all of the devices 102 may additionally include a radio 114. The radio 114 comprises a radio frequency (RF) transceiver configured to transmit and/or receive RF signals via one or more of a plurality of channels/frequencies. In some implementations, some or all of the devices 102 includes a single radio 114 configured to send and receive data on multiple different channels, such as the control channel and multiple data channels of each communication link. The radio 114 may further be configured to implement a plurality of different modulation techniques, data rates, protocols, signal strengths, and/or power levels. The architecture 100 may represent a heterogeneous network of devices, in that the devices 102 may include different types of devices (e.g., smart meters, cellular relays, sensors, etc.), different generations or models of devices, and/or devices that otherwise are capable of transmitting on different channels and using different modulation techniques, data rates, protocols, signal strengths, and/or power levels.
The central office 104 may be implemented by one or more computing devices, such as servers, personal computers, laptop computers, routers, switches, etc. The one or more computing devices may be equipped with one or more processor(s) communicatively coupled to memory. In some examples, the central office 104 includes a centralized meter data management system that performs processing, analysis, storage, and/or management of data received from one or more of the devices 102. For instance, the central office 104 may process, analyze, store, and/or manage data obtained from a smart utility meter, sensor, control device, router, regulator, server, relay, switch, valve, and/or other devices. The central office 104 may additionally or alternatively include a network management system (NMS) for maintaining a registry of devices of the AMI network, device configuration settings, version information, and the like. Although the example of FIG. 1 illustrates the central office 104 in a single location, in some examples the central office may be distributed amongst multiple locations and/or may be eliminated entirely (e.g., in the case of a highly decentralized distributed computing platform).
FIG. 2 is a schematic diagram showing additional details of the device 102 (e.g., representative device 102-3) of FIG. 1. In this example, the radio 114 includes an antenna 200 coupled to an RF front end 202 and a baseband processor 204. The RF front end 202 may provide transmitting and/or receiving functions. The RF front end 202 may include high-frequency analog and/or hardware components that provide functionality, such as tuning and/or attenuating signals provided by the antenna and obtained from one or more of the devices 102. The RF front end 202 may provide a signal to the baseband processor 204.
A frequency hopping module 208 may be configured to communicate with the baseband processor 204 and the clock 206. In one example, the frequency hopping module 208 is configured to obtain time information and/or set frequency-hopping timers in the clock 206. Such time information and/or timers will indicate to the frequency hopping module 208 when to “hop” or tune a different channel or frequency. Additionally, the frequency hopping module 208 may be configured to direct the SW defined radio or other component of the radio 114 to perform the actual frequency changes. Accordingly, the frequency hopping module 208 is able to repeatedly shift between agreed upon frequencies, at agreed upon times and communicate with another device(s) for agreed upon periods of time and in agreed upon protocols.
In some implementations, in response to determining that the requesting device 102-3 requests to join the ARA network of the neighboring device 102-2, the neighboring device 102-2 may relay the join request to the controlling device associated with the ARA network (e.g., the device 102-4). In one implementation, the neighboring device 102-2 may know an address (e.g., an IP address) of the controlling device and may relay the join request to the controlling device through the relay module 224. By way of example and not limitation, the relay module 224 may include a relay agent, e.g., a DHCPv6 relay agent, to relay the (DHCPv6) join request sent from the requesting device 102-3 to the controlling device. For example, the relay module 224 of the neighboring device 102-2 may insert the IP address of the controlling device as a destination address of a data packet including the join request of the requesting device 102-3 and relay the data packet to the controlling device directly or indirectly through a parent device of the neighboring device 102-2.
Additionally or alternatively, regardless of whether the join request is relayed to the controlling device or the parent device of the neighboring device 102-2, the neighboring device 102-2 may further encrypt the relayed request using an encryption key of the neighboring device 102-2. In one implementation, this encryption key may include a group key associated with the ARA network and distributed to each device 102 in the ARA network. In some implementations, this encryption key may include an encryption key selected from the pool of encryption/decryption keys accessible by each device 102 of the ARA network and/or assigned to the neighboring device 102-2. In some other implementations, the neighboring device 102-2 may relay the request in a plain format, i.e., without encryption. In one implementation, the neighboring device 102-2 may use an address thereof as a source address of the request (or replace the source address of the join request of the requesting device 102-3 by the address of the neighboring device 102-2) that the neighboring device 102-2 is going to relay on behalf of the requesting device 102-3. This allows proper forwarding of a reply from other devices or servers associated with the ARA network back to the requesting device 102-3. For example, a response or reply (e.g., for the join request) to the requesting device 102-3 may use the address of the neighboring device 102-2 as the destination address, and request the neighboring device 102-2 to forward or relay the response or reply to the requesting device 102-3 accordingly.
Upon receiving the reply to the join request, the requesting device 102-3 may configure configuration parameters for communication within the ARA network based on, for example, the configuration information or parameters included in the reply. For example, the requesting device 102-3 may attach to a routing topology into the ARA network by deciding which routing path and/or neighboring device to use if more than one routing path and/or neighboring devices are available. Additionally or alternatively, the requesting device 102-3 may send a message to the root node of the ARA network to notify its arrival to the ARA network, for example. The requesting device 102-3 may or may not request or need an acknowledgement from the root node. In an event that an acknowledgement from the root node is requested or needed, the requesting device 102-3 may wait for an acknowledgement sent from the root node. In one implementation, if no acknowledgement is received from the root node for a predetermined period of time, the requesting device 102-3 may resend the message to the root node. The requesting device 102-3 may resend the message for a predetermined number of receipt failures of acknowledgement. Additionally or alternatively, the requesting device 102-3 may select a different routing path and/or neighboring device 102 to forward or relay the message to the root node. Upon receiving an acknowledgement from the root node, the requesting device 102-3 may start performing normal operations in the ARA network, including, for example, routing and/or forwarding packets that are not destined to the requesting device 102-3, processing packets addressed to the requesting device 102-3, replying for packets (if requested) that are destined to the requesting node 102-3, etc. If no acknowledgement is received from the root node for a predetermined number of retries, the requesting device 102-3 may start performing normal operations as if an acknowledgement has been received from the root node, resending the arrival message again after a predetermined time interval, or deciding to migrate migrating to another adjacent ARA network if available, etc.
In some implementations, a device 102 within an ARA network may decide or initiate to leave or migrate from the ARA network to another ARA network. By way of example and not limitation, the device 102 may decide or initiate to leave or migrate from an ARA network (where the device 102 is currently attached) to another ARA network based on one or more network conditions associated with the device 102 and/or the ARA network. For example, the device 102 may initiate to migrate from the ARA network to another ARA network if a communication quality (e.g. a link-layer communication quality) with the device 102 is poor or degraded, for example, below a predetermined quality threshold. Additionally or alternatively, the device 102 may migrate from the ARA network to another ARA network if the router of the ARA network fails. Additionally or alternatively, the device 102 may, while attached to the current ARA network, listen in an environment thereof, and detect or discover existence of other adjacent ARA networks. The device 102 may learn about performance such as quality of service (QoS) offered by these adjacent networks. The device 102 may migrate from the ARA network to another ARA network if the other ARA network offers a better performance such as quality of service than the ARA network to which the device 102 is currently attached. In one implementation, the device 102 may select an adjacent ARA network for migration based on one or more policies or criteria. Examples of these policies or criteria may include, but are not limited to, selecting a network that offers at least a predetermined amount or percentage of improvement over performance such as QoS, time or response latency, throughput, packet drop rate, etc., as compared to the ARA network to which the device 102 is currently attached.
In one implementation, during a time period of the migration and before completion of the migration, the device 102-5 may maintain connection or attachment to the ARA network to which it is currently or originally attached. For example, the device 102-5 may still perform normal operations in the current ARA network, including routing and forwarding packets not destined to the device 102-5, processing packets addressed to the device 102-5, replying for the packets destined to the device 102-5—if requested—via the current ARA network, etc. Additionally or alternatively, the device 102-5 may select a neighboring device 102 from the new ARA network and employ this neighboring device 102 as a relay and/or forwarding device for data packets. Additionally or alternatively, the device 102-5 may still receive data packets destined to its old address from other devices 102 in the ARA network. In some implementations, during the time period of the migration, the device 102-5 may store or cache its old address and continue to process data or data packets addressed to its old address as usual, thus maintaining a connectivity with the ARA network it is migrating from during this time period of the migration. In one implementation, if the device 102-5 has lost connection with its parent devices of the ARA network it is migrating from, the device 102-5 may drop all upstream packets (data packets transmitted to devices in a higher hierarchical level of the ARA network) from its buffer, for example. In some implementations, the device 102-5 may forward the received data packets to the ARA network it is migrating from (if still attached) during the time period of the migration. In one implementation, if the device 102-5 receives its new address and is now attached to the another ARA network (i.e., the new ARA network), the device 102-5 may “tunnel” the buffered data packets, i.e., data packets coming from its “old” ARA network, and send the received data packets (which are included or encapsulated into new packets, for example) using its new address through the new ARA network, for example.
In some implementations, the old address of the device 102-5 will not be re-distributed to another device during a certain period of time, called as a migration time period. This migration time period is set to be long enough to cover an entire ARA switching process until an entire system (including, for example, the root nodes of the old and new ARA networks, DNS server, etc.) is updated to reflect the migration of the device 102-5.
FIG. 3 is a flow chart depicting an example method 300 of device registration in a network. FIG. 4 is a flow chart depicting an example method 400 of determination whether to allow or reject a device to join a network. FIG. 5 is a flow chart depicting an example method 500 of device migration from a network. The methods of FIG. 3, FIG. 4 and FIG. 5 may, but need not, be implemented in the environment of FIG. 1 and using the device of FIG. 2. For ease of explanation, methods 300, 400 and 500 are described with reference to FIGS. 1 and 2. However, the methods 300, 400 and 500 may alternatively be implemented in other environments and/or using other systems.
At block 316, upon receiving the message, the authentication server 120 may decrypt the message if encrypted, and parse the message to obtain the identifier and/or the authentication signature of the requesting device 102-3. The authentication server 120 may then perform authentication based on the obtained identifier and/or the obtained authentication signature of the requesting device 102-3. In response to successfully authenticating an identity of the requesting device 102-3, the authentication server 120 may send a successful authentication message possibly including a group key associated with the network (which may or may not be encrypted using a public or symmetric key of the requesting device 102-3) to the controlling device 102-4. In one implementation, the public or symmetric key of the requesting device 102-3 may be known only to the requesting device 102-3 and the authentication server 120. In some implementations, the public or symmetric key of the requesting device 102-3 may further be known to other devices or servers (such as the central office 104 and/or the controlling device 102-4, for example) of the ARA network that are responsible for network management or monitoring. For example, the authentication server 120 may send the successful authentication message that further includes the public or symmetric key of the requesting device 102-3 that has been encrypted using the group key associated with the ARA network. Alternatively, if the authentication server 120 fails to authenticate the identity of the requesting device 102-3, the authentication server 120 may send a failed authentication message to the controlling device 102-4, indicating that the authentication is failed.
At block 320, the neighboring device 102-2 may receive and parse the admission response sent from the controlling device 102-4. In one implementation, if the response is encrypted using the group key associated with the network, the neighboring device 102-2 may decrypt the encrypted response. In one implementation, in response to determining that the admission response is a response related to the join request of the requesting device 102-3, the neighboring device 102-2 may relay part or all of the response to the requesting device 102-3. For example, the neighboring device 102-2 may relay part of the response that is encrypted using the public or symmetric key of the requesting device 102-3 to the requesting device 102-3.
At block 324, the controlling device 102-4 may optionally send a registration request to the NMS to register the requesting device 102-3 with the NMS or the central office 104. The registration request may include, but is not limited to, an identifier of the requesting device 102-3.
At block 328, in response to obtaining the configuration information or parameters from the NMS, the controlling device 102-4 may assign a new address to the requesting device 102-3. In one implementation, the controlling device 102-4 may assign a new address that includes a prefix specified or designated to the network. The controlling device 102-4 may further prepare a reply (e.g., a DHCP reply) to the requesting device 102-3. In one implementation, the reply may include, but is not limited to, the assigned new address, the configuration information or parameters, and/or the group key associated with the network. In one implementation, if the controlling device 102-4 has not sent an admission response to the requesting device 102-3 immediately after determining that the identity of the requesting device 102-3 is successfully authenticated, sending this reply from the controlling device 102-4 may indicate the successful authentication of the identity of the requesting device 102-3. In some implementations, the controlling device 102-4 may further merge information received from the authentication server 120 related to the authentication of the identity of the requesting device 102-3 into the reply. In one implementation, the controlling device 102-4 may send the reply to the requesting device 102-3 via the neighboring device 102-2 (and a router heading the network if the controlling device is located outside the network).
At block 512, during a time period of migration and before completion of the migration, in response to receiving data packets destined to an “old” address (i.e., an address assigned to the device 102-5 by the network from which the device 102-5 is leaving or migrating) of the device 102-5, the device 102-5 may drop the data packets, or forward the data packets to other devices in the network that the device 102-5 is still connected to.
1. One or more non-transitory computer-readable media having computer-readable instructions therein that, when executed by one or more processors, perform acts comprising:
receiving, at a utility metering device, an instruction to leave a current network to which the utility metering device is currently connected;
in response to receiving the instruction, determining whether one or more other networks exist that the utility metering device is capable of joining;
responsive to determining that one or more other networks exist that the utility metering device is capable of joining, selecting a network from the one or more other networks and sending a request to join the selected network; and
responsive to determining that the utility metering device is incapable of joining any other network, sending, by the utility metering device, a response to the current network indicating that the utility metering device is unable to leave the current network.
2. The one or more non-transitory computer-readable media of claim 1, the acts further comprising:
receiving a response from the selected network indicating that the utility metering device is allowed to join the selected network; and
migrating from the current network to the selected network based on information provided in the response from the selected network.
3. The one or more non-transitory computer-readable media of claim 2, wherein the information provided in the response from the selected network comprises a group key associated with the selected network, configuration information for the utility metering device to join the selected network, and a new address assigned to the utility metering device.
4. The one or more non-transitory computer-readable media of claim 3, the acts further comprising updating an old address of the utility metering device with the new address and receiving packets destined to the new address upon the migrating.
5. The one or more non-transitory computer-readable media of claim 2, the acts further comprising:
prior to a completion of the migrating and in response to receiving a packet at an old address of the utility metering device:
dropping the received packet;
forwarding the received packet to the current network when a connection between the utility metering device and the current network still exists; or
including the received packet in a new packet and sending the new packet using a new address of the utility metering device upon receiving a new address assigned to the utility metering device.
6. A utility metering device, comprising:
a transceiver communicatively coupled to the processor and to a current network,
receive, via the transceiver, an instruction to leave the current network to which the utility metering device is currently connected;
in response to receiving the instruction, determine whether one or more other networks exist that the utility metering device is capable of joining;
responsive to determining that one or more other networks exist that the utility metering device is capable of joining, select a network from the one or more other networks and send a request to join the selected network; and
responsive to determining that the utility metering device is incapable of joining any other network, send a response to the current network indicating that the utility metering device is unable to leave the current network.
7. The utility metering device of claim 6, wherein the processor is further configured to:
receive a response from the selected network indicating that the utility metering device is allowed to join the selected network; and
migrate from the current network to the selected network based on information provided in the response from the selected network.
8. The utility metering device of claim 7, wherein the information provided in the response from the selected network comprises a group key associated with the selected network, configuration information for the utility metering device to join the selected network, and a new address assigned to the utility metering device.
9. The utility metering device of claim 8, wherein the processor is further configured to:
update an old address of the utility metering device with the new address; and
receive packets destined to the new address upon the migrating.
10. The utility metering device of claim 7, wherein the processor is further configured to, prior to a completion of the migrating and in response to receiving a packet at an old address of the utility metering device:
drop the received packet;
forward the received packet to the current network when a connection between the utility metering device and the current network still exists; or
include the received packet in a new packet and send the new packet using a new address of the utility metering device upon receiving a new address assigned to the utility metering device.
11. A method of evaluating an instruction to leave a network, the method comprising:
13. The method of claim 12, wherein the information provided in the response from the selected network comprises a group key associated with the selected network, configuration information for the utility metering device to join the selected network, and a new address assigned to the utility metering device.
updating an old address of the utility metering device with the new address and receiving packets destined to the new address upon the migrating.
15. The method of claim 12, further comprising, prior to a completion of the migrating and in response to receiving a packet at an old address of the utility metering device:
US13/481,649 2012-05-03 2012-05-25 Efficient device handover/migration in mesh networks Active US9591525B2 (en)
EP12166697 2012-05-03
EP12166697.8 2012-05-03
EP12166697.8A EP2661127B1 (en) 2012-05-03 2012-05-03 Efficient device migration in mesh networks
US13/481,649 US9591525B2 (en) 2012-05-03 2012-05-25 Efficient device handover/migration in mesh networks
US15/425,222 US20170150400A1 (en) 2012-05-03 2017-02-06 Efficient device handover/migration in mesh networks
PCT/US2012/036838 Continuation WO2013165444A1 (en) 2012-05-03 2012-05-07 Efficient device handover/migration in mesh networks
US15/425,222 Continuation US20170150400A1 (en) 2012-05-03 2017-02-06 Efficient device handover/migration in mesh networks
US20130294230A1 US20130294230A1 (en) 2013-11-07
US9591525B2 true US9591525B2 (en) 2017-03-07
ID=49512430
US13/481,649 Active US9591525B2 (en) 2012-05-03 2012-05-25 Efficient device handover/migration in mesh networks
US15/425,222 Pending US20170150400A1 (en) 2012-05-03 2017-02-06 Efficient device handover/migration in mesh networks
US (2) US9591525B2 (en)
WO2016131195A1 (en) * 2015-02-17 2016-08-25 华为技术有限公司 Data transmission method and device
US10342024B1 (en) * 2015-11-12 2019-07-02 Sprint Spectrum L.P. Methods and systems for assigning resources to user equipment devices
JP2001326658A (en) 2000-03-10 2001-11-22 Fujitsu Ltd Network load managing unit, communication unit, communication method, medium and program
US20060140411A1 (en) 2002-09-30 2006-06-29 Yanmin Zhu Ciphering key management and distribution in mbms
JP2006262206A (en) 2005-03-17 2006-09-28 Ricoh Co Ltd Network system and terminal device
JP2007081520A (en) 2005-09-12 2007-03-29 Kddi Corp Data transmission system and communication terminal device
US20080037479A1 (en) 2006-08-14 2008-02-14 Motorola, Inc. System and method for routing and domain name system support of a mobile node
US20100269155A1 (en) 2002-07-31 2010-10-21 Ralph Droms Method and Apparatus for Registering Auto-Configured Network Addresses Based On Connection Authentication
JP2010268322A (en) 2009-05-15 2010-11-25 Nippon Telegr & Teleph Corp <Ntt> Information distribution system and information distribution method
JP2011109412A (en) 2009-11-17 2011-06-02 Mitsubishi Electric Corp Node device, ad hoc network system, and method of participating in network
US20110142042A1 (en) * 2009-12-11 2011-06-16 Comcast Cable Communications, Llc Internet Protocol Multicast Content Delivery
JP2011130387A (en) 2009-12-21 2011-06-30 Mitsubishi Electric Corp Relay apparatus and radio communication system
US20110206191A1 (en) 2010-02-24 2011-08-25 General Motors Llc Method of posting a voice related message on a remotely accessible networking page
US20130018993A1 (en) 2011-07-12 2013-01-17 Cisco Technology, Inc. Efficient use of dynamic host configuration protocol in low power and lossy networks
2012-05-25 US US13/481,649 patent/US9591525B2/en active Active
2017-02-06 US US15/425,222 patent/US20170150400A1/en active Pending
JP2010141890A (en) 2008-12-15 2010-06-24 Ind Technol Res Inst Method and system for node join to wireless ad-hoc network
Australian Examination Report dated Sep. 5, 2016 for Australian Patent Application No. 2016200625, 2 pages.
Canadian Office Action dated Nov. 2, 2016, for Canadian Patent Application No. 2,869,150, 3 pages.
Canadian Office Action, mailed Aug. 3, 2016, for Canadian Patent Application No. 2869147, 4 pages.
Communication pursuant to Article 94(3) EPC for European Patent Appl. No. 12166694.5, dated Aug. 5, 2016, 6 pages.
Copy of Japanese Notice of Rejection, with English translation, mailed Dec. 15, 2015, for Japanese Patent Application No. 2015-510240, 13 pages.
Dharia et al., (A novel distributed resource-aware scalable scheme for Scatternet formation), herein after referred to as Dharia is considered by IDS filed in Aug. 12, 2014. *
Dharia, et al., "A Novel Distributed Resource-Aware Scalable Scheme for Scatternet Formation", The 11th IEEE International Conference on Networks, Sep. 28-Oct. 1, 2003, pp. 659-664.
Droms, "Authentication for DHCP Messages," Jun. 1, 2001; available at <<http://www.sanface.com/txt2pdf.html>>, 18 pages.
Droms, "Authentication for DHCP Messages," Jun. 1, 2001; available at >, 18 pages.
Examination Report for Australian Patent Appl. No. 2012379055, dated Apr. 11, 2016, 3 pages.
Japanese Notice of Allowance, with English translation, mailed Jun. 28, 2016, for Japanese Patent Application No. 2015-510240, 6 pages.
Japanese Office Action mailed Mar. 29, 2016, with English translation, for Japanese Patent Application No. 2015-510241, 10 pages.
Japanese Office Action mailed Oct. 18, 2016, with English translation, for Japanese Patent Application No. 2015-510241, 6 pages.
Marin-Lopez et al., "Network Access Security for the Internet: Protocol for Carring Authentication for Network Access," IEEE Communications Magazine, IEEE Service Center, Piscataway, US, vol. 50, No. 3, Mar. 1, 2012, pp. 84-92.
Notice of Acceptance mailed Apr. 20, 2016, for Australian Patent Appl. No. 2012379054, 2 pages.
Office Action dated Nov. 25, 2016, for U.S. Appl. No. 14/880,449, 17 pages.
Office action for U.S. Appl. No. 13/481,617, mailed on Sep. 3, 2013, Popa et al., "Authentication Using DHCP Services in Mesh Networks," 10 pages.
Office Action for U.S. Appl. No. 14/296,765, mailed on Jan. 9, 2015, Daniel Popa, "Authentication Using DHCP Services in Mesh Networks", 12 pages.
Orhan et al., "Measurement-Based Admission Control in Wireless Sensor Networks," Eleventh International Conference on Mobile Date Management, MDM, IEEE, May 23, 2010, pp. 426-431.
Qiu et al., "An Efficient Self-healing Process for ZigBee Sensor Networks," International Symposium on Communications and Information Technologies, 2007, ISCIT, IEEE, Oct. 1, 2007, pp. 1389-1394.
The Australian Office Action mailed Apr. 16, 2015 for Australian Patent Application No. 2012379054, a counterpart foreign application of U.S. Pat. No. 8,755,385, 2 pages.
The European Office Action mailed Jun. 27, 2014 for European Patent Application No. 12166697.8, a counterpart foreign application of U.S. Appl. No. 13/481,649, 7 pages.
The Extended European Search Report mailed Jan. 14, 2013 for European patent application No. 12166697.8, 10 pages.
The Extended European Search Report mailed Oct. 24, 2012 for European patent application No. 12166694.5, 7 pages.
The Partial European Search Report mailed Sep. 26, 2012 for European patent application No. 12166697.8, 8 pages.
The PCT Search Report mailed Feb. 25, 2013 for PCT application No. PCT/US12/36832, 9 pages.
The PCT Search Report mailed Jan. 24, 2013 for PCT application No. PCT/US12/36838, 10 pages.
U.S. Appl. No. 13/481,617, filed on May 25, 2012, Daniel Popa, Mehdi Mani, Michael T. Garrison Stuber, "Authentication Using DHCP Services in Mesh Networks," 74 pages.
US Office Action mailed May 19, 2016, for U.S. Appl. No. 14/880,449, 18 pages.
Yi et al., "Securing Wireless Sensor Networks," Third International Conference on Availability, Reliability, and Security, IEEE, Mar. 4, 2008, pp. 497-502.
US10264588B2 (en) * 2015-08-19 2019-04-16 Gojo Industries, Inc. Wireless sensor network
US20130294230A1 (en) 2013-11-07
US20170150400A1 (en) 2017-05-25
JP4860381B2 (en) 2012-01-25 Wireless communication system, the system controller, a radio base station, a wireless communication terminal, communication control method, and communication control program
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:POPA, DANIEL;MAINAUD, BASTIEN;MANI, MEHDI;AND OTHERS;SIGNING DATES FROM 20120523 TO 20120524;REEL/FRAME:028282/0895
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ITRON FRANCE S.A.S.;REEL/FRAME:039373/0137
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ITRON, INC.;REEL/FRAME:039373/0107