US10251073B2 - Method for configuring a node device, a network and a node device - Google Patents

Method for configuring a node device, a network and a node device Download PDF

Info

Publication number
US10251073B2
US10251073B2 US15/124,309 US201515124309A US10251073B2 US 10251073 B2 US10251073 B2 US 10251073B2 US 201515124309 A US201515124309 A US 201515124309A US 10251073 B2 US10251073 B2 US 10251073B2
Authority
US
United States
Prior art keywords
routing
node
node device
instance
local
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US15/124,309
Other languages
English (en)
Other versions
US20170019804A1 (en
Inventor
Oscar Garcia Morchon
Sahil Sharma
Alfonso De La Vega Ruiz
David Perera Barreda
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Signify Holding BV
Original Assignee
Philips Lighting Holding BV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Philips Lighting Holding BV filed Critical Philips Lighting Holding BV
Publication of US20170019804A1 publication Critical patent/US20170019804A1/en
Assigned to KONINKLIJKE PHILIPS N.V. reassignment KONINKLIJKE PHILIPS N.V. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PERERA BARREDA, David, MORCHON, OSCAR GARCIA, SHARMA, SAHIL, DE LA VEGA RUIZ, Alfonso
Application granted granted Critical
Publication of US10251073B2 publication Critical patent/US10251073B2/en
Assigned to SIGNIFY HOLDING B.V. reassignment SIGNIFY HOLDING B.V. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KONINKLIJKE PHILIPS N.V.
Assigned to SIGNIFY HOLDING B.V. reassignment SIGNIFY HOLDING B.V. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: PHILIPS LIGHTING HOLDING B.V.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/69—Spread spectrum techniques
    • H04B1/713—Spread spectrum techniques using frequency hopping
    • H04B1/7136—Arrangements for generation of hop frequencies, e.g. using a bank of frequency sources, using continuous tuning or using a transform
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1845—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast broadcast or multicast in a specific location, e.g. geocast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B2201/00—Indexing scheme relating to details of transmission systems not covered by a single group of H04B3/00 - H04B13/00
    • H04B2201/69—Orthogonal indexing scheme relating to spread spectrum techniques in general
    • H04B2201/713—Frequency hopping
    • H04B2201/71323—Adaptive systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/32—Connectivity information management, e.g. connectivity discovery or connectivity update for defining a routing cluster membership

Definitions

  • the present invention relates to communication devices in a communication network, for example an outdoor lighting network where each node device is connected to a luminaire that is controlled by commands sent over the network.
  • the invention is also relevant for methods for configuring such nodes.
  • This invention is, for example, relevant for outdoor lighting networks using wireless communication.
  • each node device has two or more communication interfaces.
  • each node 100 of the network has a mesh interface 101 and a GPRS interface 102 for example.
  • the GPRS interface 102 is used for performing the auto-commissioning with a backend, e.g., by means of UDP/DTLS/CoAP. In this sense, if the DTLS handshake is successful, the device can be registered and some configuration parameters can be sent to the device. Once all the node devices 100 have been commissioned, the mesh network can be configured and the networking parameters transmitted to a remote controller 110 over the GPRS connection.
  • the GPRS module of some of the node devices 100 can be disabled so that those devices with a disabled GPRS talk to the backend only over the remaining devices that still have a GPRS interface enabled (e.g. node device 100 a ).
  • this device 100 a can act as a simple router further simplifying the overall communication architecture and ensuring end-to-end operation between the network and the remote controller 110 in the backend. This means that a part of the communication is done over the mesh network and another part over the GPRS network.
  • the GPRS interface can also be another long range communication interface such as UMTS, LTE or even a long range sub-GHz radio with which the devices can communicate in a star topology in a long range.
  • Multicast communication from the backend to a set of devices in the lighting system this can be used for a software update or for switching on/off a group of luminaires (Downlink Multicast).
  • Routing Protocol for Low-power and lossy Networks RPL
  • a RPL-based network is composed by RPL instances. Each of these RPL instances can have one or more Destination Oriented Directed Acyclic Graphs (DODAGs). Each DODAG ends in a special node called root.
  • DODAGs Destination Oriented Directed Acyclic Graphs
  • a node can only join one DODAG within an RPL instance, and communications between DODAGs of the same instance are not possible (they are isolated).
  • a node can join different RPL instances at the same time.
  • a node could own or be part of multiple local instances.
  • a device comprising a routing controller for routing messages to a plurality of node devices of a network, the routing controller comprising
  • the neighbor node device is selected regardless whether the neighbor node device belongs to the routing set of node devices
  • routing controller is configured to use the local instance for routing of multicast messages to the node devices.
  • the local instance can be used to reach neighboring nodes that are not reachable with the global instance and that are part of another subnetwork. Then, the nodes of this other subnetwork can use their own global instance to route messages to nodes of their subnetwork. By routing the multicast messages with the local instance, this enables to avoid to route messages more efficiently.
  • the global instance comprises at least one destination oriented directed acyclic graph defining the routes, linking the node devices of the routing set and having as a root a node device being a router device bridging the network to a backend.
  • This first embodiment enables, for example, to avoid to route messages through the backend and directly to a neighboring subnetwork through one of the routes proposed by the local instances. This is particularly interesting for applications requiring local communication or for multicast of messages.
  • the routing controller is configured to use the global instance for unicast messages and for multicast messages from the backend.
  • the global instance can be used instead of the local instance for routing messages, offering more flexibility in the routing of messages.
  • communication between the backend and the network is carried out over a transmission medium which is different from the transmission medium of the network.
  • This can be a long range communication medium, like GPRS or LTE.
  • a method for configuring a node device in a network said node device comprising a routing controller for routing messages to other node devices of a network, the method comprising the steps of
  • step (b) creating at least one local instance for routing packets to a neighbor node device neighboring the node device, wherein step (b) includes selecting the neighbor node device regardless whether the neighbor node device belongs to the routing set of other node devices,
  • the local instance can be used to reach neighboring nodes that are not reachable with the global instance and that are part of another subnetwork. Then, the nodes of this other subnetwork can use their own global instance to route messages to nodes of their subnetwork. By routing the multicast messages with the local instance, this enables to route messages more efficiently. This is particularly adapted to the use of applications involving local communication where a plurality of neighboring node devices have to be informed of the detection of a moving person or vehicle, so that the neighboring devices can be switched on accordingly.
  • the configuration of local instances in step (c) used with a physical interface is done by means of a message exchanged over another physical interface.
  • the configuration of local instances in step (b) comprises assigning to the node device a local instance in which the node device acts as a root and assigning identifiers of other local instances in which the node device acts as a listener.
  • step (a) further comprises creating at least one destination oriented directed acyclic graph defining the routes linking the node devices of the routing set and having as a root a node device being a router device bridging the network to a backend.
  • the node device is configured to use the global instance instead of the local instance for routing messages, offering more flexibility in the routing of messages.
  • step (b) further comprises creating a destination oriented directed acyclic graph defining the route linking the neighbor device to the node device.
  • step (a) and step (b) are carried out based on respective geographical information of the node device and the other node devices. Thanks to the respective information of the node device, the local instance can be configured so that it creates a communication bridge or link between two isolated subnetworks formed by the global instance routing scheme. For example, the global instances and the local instances can select node devices to ensure that any different global instance is bridged by one or more local instances. This permits in some embodiments to avoid the routing of messages through the backend which would be inefficient. This could also be costly, since it may require for example GPRS resources which are charged to the service provider.
  • the method comprises the step of the node devices of the network transmitting their respective geographical information to a central controller in the backend, and steps (a)-(c) are carried out from said central controller.
  • the node device may include for example a GPS chipset to establish their geographic information in an accurate manner and transmit these to the central controller in the backend. Geographical information might also be obtained by other means, e.g., from the cellular network.
  • the central controller in the backend has more computation power than the node devices to create and configure in an optimized manner the routing schemes to be used by the network.
  • steps (a)-(c) are carried out from a central controller in the backend. It may not be necessary for the node devices to transmit their geographical information since these may be known in advance for example from the installation map.
  • step (b) comprises creating a MPL interface (where before we had a local RPL instance) for the MPL protocol, and the node device is the unique seed of the MPL protocol.
  • step (a) comprises creating a MPL interface in the global instance for the MPL protocol, and wherein a router node connected to the backend is the unique seed of the MPL protocol.
  • the Multicast Protocol for Lossy and low-power networks is a candidate for 6LoWPAN in view of its properties and its efficiency in such networks.
  • steps (a) and (b) comprise creating an RPL interface in the local instance and global instance for the RPL protocol.
  • the local instances are defined with a routing tree which is of the minimum depth. This means for example that all the nodes listed in the local instances can be reached in one hop (no intermediary retransmission required). This enables simplicity and efficiency in the routing of messages. Obtaining these trees of minimum depth is particularly simple if they are computing in the backend having global knowledge of the network and the exact geographical location of the devices.
  • the local instance defines routes by means of a tree structure, having a root, intermediary nodes and leaves, and wherein messages routed from the root to the leaves in the local instance are multicast more than one time by the root and all the intermediate nodes to ensure reliability. By repeating the message which is multicast, this allows to maintain reliability in the transmission of messages.
  • FIG. 1 is a block diagram of a network in which the invention can be implemented.
  • FIG. 2 is the representation of the routing instances in a network comprising nodes in accordance with an embodiment of the invention.
  • FIG. 3A-3D show the routing of packets in the network of FIG. 2 .
  • FIG. 4 is a flowchart representing a method for configuring the network in accordance with another embodiment of the invention.
  • FIG. 5 is the representation of the routing instances in a network comprising nodes in accordance with another embodiment of the invention.
  • FIG. 6 is the representation of the routing instances in a network comprising nodes in accordance with still another embodiment of the invention.
  • the present invention relates to node devices in a network and to a method for configuring such node device to enable the routing of messages in the network.
  • multicast can be used to switch on or off a group of luminaires or to inform a group of luminaires of a detected object in the vicinity of a node device.
  • Multicast Protocol for Low power and lossy networks is a protocol that will be used for multicast in 6LoWPAN networks.
  • the main features of MPL protocol are as follows:
  • RPL can be used to create routing entries.
  • RPL fits well for a unicast communication pattern.
  • MPL is a good option for multicast communication.
  • a first embodiment of the invention makes use of global and local RPL instances for achieving all communication goals.
  • a plurality of node devices 100 and 100 a are interconnected and form different subnetworks N1 and N2.
  • the node devices 100 and 100 a are connected to each other by means of their mesh interface.
  • the node devices 100 a however further operate as border routers using their GPRS interface to communicate with a backend network 200 , connected to a remote controller (not shown).
  • links can be created between the different subnetworks N1 and N2 that would have been otherwise isolated.
  • the local instance 22 a is bridging on the two subnetworks and enables communications from the network N1 to the network N2 without going through the backend.
  • it can be preferred to create local instances including nodes that are not already included in the global instance in order to increase the probability of creating multiple links with other subnetworks.
  • node devices 1001 - 1008 Several local instances are then shown, each dedicated to a considered node. For the sake of clarity, only the local instances of the eight node devices ( 1001 - 1008 ) at the bottom of the network are shown. However, intermediate node devices or border routers nodes also have local instances to route messages to their respective neighbours. For example, the local instance of node 1001 shows how the local instance of this node device 1001 routes messages to node devices 1002 and 1003 .
  • FIG. 3A shows the routing of a unicast message from the router using the global instance.
  • a data packet is routed in a unicast manner from the backend 200 to the node device 1003 .
  • the global instance can be used to route any unicast message from the backend to any of the devices. This can be used for example by the remote controller to command a single luminaire to switch on or off.
  • FIG. 3B shows the routing of a unicast message from node 1005 towards the router node and then the backend using the global instance. This can be used for the node devices to route messages that feedback for example some information on a state of the luminaire or the amount of energy consumed by the luminaire.
  • FIG. 3C shows the routing of a multicast message from the backend to a group of luminaires. This can be used for spreading configuration parameters to a group of luminaires or for example to switch on or off a group of luminaires.
  • the routing is shown by FIG. 3D .
  • the local instance is used to route messages.
  • the node 1005 can reach by multicast the neighboring nodes 1003 , 1004 , 1006 and 1007 .
  • the nodes 1006 and 1007 are reached by the node device 1005 although not in the same network.
  • the messages can navigate and reach the other subnetworks faster, and does not require to go through the backend 200 .
  • the local instances are defined with a routing tree which is of the minimum depth. This means that from the node device serving as the root, all the other nodes can be reached in the minimum number of hops. Typically, the minimum number of hops is 1, i.e. the root node can reach directly all the nodes listed in the local instance.
  • Each node can own several local instances, which could result in a versatile response depending on the situation. If the instances are created following different application requirements, the network could react to an event at the routing level in function of its application needs (cross-layer optimization). For example, if we have a few instances based on the distance or number of hops we want a message to travel and that something in the environment is detected, the network will be able to spread the message to few hops (e.g. detection of a slow moving object like a person) or it can be decided to send it as far as possible (e.g. detection of fast moving object like a car). Also, in the car scenario, it is possible to spread the messages only in the direction the car is going.
  • cross-layer optimization For example, if we have a few instances based on the distance or number of hops we want a message to travel and that something in the environment is detected, the network will be able to spread the message to few hops (e.g. detection of a slow moving object like a person) or it can be decided to send
  • the creation of the instances and optionally of the associated DODAG can be done in the backend.
  • the backend will run algorithms based on metrics such as position, line of sight, distance between nodes and signal strength.
  • Some of this metrics will be sent from the nodes to the backend via GPRS during or after the commissioning phase.
  • the remaining metrics will be calculated by the backend with geographical information (geographic position of the nodes).
  • geographical information geolocation of the nodes.
  • all node devices have a GPS module, the position of each node device could be sent, for example through GPRS during the commissioning, with the metrics mentioned before.
  • the backend starts the algorithms, for example based on the received geographic information and creates a set of network parameters for each node. Finally the Backend will push the network parameters to each node through GPRS.
  • the creation of the local instances is facilitated by the global information of the network.
  • global information can be computed with the position of the GPS, or in a variant based on location information stored during the installation of the network.
  • This algorithm For the creation of each local instance, the following algorithm can be executed at the backend.
  • This algorithm has as input the set of nodes which are to join the local instance and includes several functions.
  • This algorithm generates the structure with minimum number of hops. This is achieved by adding one hop more in every iteration only if the links are valid.
  • the validation of the link can be varied or adjusted for example based on the situation (environment, proximity of interference sources) and on the required performance of the network. For each node the algorithm will add the best link for it (which will be a node of the previous iteration).
  • Input There are two principal inputs for this algorithm: Node which will become the root of our hierarchical structure. Set of nodes we want to include in the topology we are creating. The determination of this set of nodes is not defined by this algorithm. Also, we need metrics information to decide whether a link is suitable for the communication or if it does not have enough quality to be used. Output: List of nodes with associated parent into the instance. Nodes which could not join the structure. This can happen if there is no link which fulfills the communication requirements.
  • the computation of the set of nodes could be different depending on the application (e.g: a car going in one specific direction or a person walking will not need the same scope, as explained in feature 1) or all the nodes in a given area cantered in a given location. So, each node could have more than one local instance for each application purpose.
  • This algorithm can be run in the backend, as mentioned previously. In that feature, the main metrics are mentioned too. This metrics will be used in a cost function, which will be called in the next functions:
  • valid_link(node1, node2) Checks if the link between two nodes is good enough to be used Input: node1 and node2 which form the link to be verified Output: True if the link between node1 and node2 is suitable. False otherwise.
  • best_link(node, parent1, parent2) Given two possibilities, returns the best parent for a node. Input: • node : Node we are looking a parent for. • parent1 : First option. • parent2 : Second option. Output: Best parent between the two available. look_for_parent(node, list): Searchs for the best parent for a node inside the list of available parents at the moment Input: • node : Node we are looking a parent for.
  • look_for_parent(node, list) Searchs for the best parent for a node inside the list of available parents at the moment.
  • • list Available nodes to become parent of that node.
  • temporal_parent null 2 for all n in list do 3: if valid_link(node, n) then 4: if temporal_parent is null then 5: temporal_parent n 6: else 7: temporal_parent best_link(node, temporal_parent, n) 8: end if 9: end if 10: end for 11: return temporal_parent look_for_parents(included, look_for): Searches for the best parent for a set of nodes inside a list of possible parents Input: • included : List of nodes which are already in the structure. • look_for : Nodes that still need a parent.
  • the RPL local instances provide a good solution for enabling all the communication use cases.
  • a consideration is whether RPL can be improved by adding features of MPL. We can apply this protocol in both global and local instances with this structure. In local instances:
  • a method for configuring a network is illustrated in the flowchart.
  • the method comprises the steps of
  • the node devices of the network transmit their respective geographical information to a central controller in the backend.
  • the geographical information which could also be obtained from a data storage in a variant of this embodiment, is used to optimize the global instances and the local instances in view of the nodes locations.
  • Step S 102 creating at least one local instance for routing packets to a neighbor node device neighboring the node device.
  • Step S 102 includes selecting the neighbor node device regardless whether the neighbor node device belongs to the routing set of other node devices.
  • the local instances can be configured to bridge over two networks formed by the global instances.
  • Step S 103 configuring the routing controller to use the local instances for routing of multicast messages.
  • Step S 103 comprises assigning to the node device a local instance in which the node device acts as a root and assigning identifiers of other local instances in which the node device acts as a listener.
  • each node knows all the local instances it takes part, either as the root or as a destination.
  • the steps S 101 - 103 may be carried out from the remote controller in the backend. Indeed, this entity has usually more processing power can thus optimize the configuration of the local instances and the global instances.
  • a node device i.e. device comprising a routing controller
  • uses a non-standardized application-layer solution e.g. a proprietary solution
  • non-standardized it is meant that the operation of the local instance does not necessarily follow the RPL specifications.
  • the routing in the global instance is still performed as described in the other embodiments.
  • a sensor node generates an event that needs to be delivered to a destination group of nodes.
  • the sensor transmits a packet containing event information using single-hop multicast or broadcast, named here event message.
  • event message For example, it could be a link-local IPv6 multicast UDP message.
  • the event can be for example the detection of a moving person or a moving vehicle by a motion detector, a light level detected by a light sensor.
  • the event information includes an identifier of which destination group the event needs to be communicated to.
  • the group could be specified as an IPv6 multicast destination address in an IPv6 UDP packet. Or it could be included in the payload of a UDP message. All or most direct (one-hop) neighbors of the sensor node will receive this transmission. Any nodes that are not configured to receive such transmissions, e.g. because they do not recognize the format or because destination address(es) do not match the group membership of the node, will simply discard the packet.
  • Any nodes that are configured to react to the event message will perform at least one of below tasks, depending on their configuration which one(s):
  • the event message may be modified in various ways.
  • a “Hop Limit” counter that is kept in the event message is decreased before sending or alternatively a “Hop Count” counter is increased before sending.
  • a sending node also checks based on the counter if the message can still be re-broadcasted based on configured maximum hops limits. Such function helps to limit the number of nodes over which an event message is spread by this method, to prevent network congestion.
  • a node waits a random time period before attempting re-transmission to help prevent congesting the wireless network.
  • a node is configured to repeat the re-transmission a number of times, e.g. 3 times with random waiting intervals, or multiple times with varying waiting intervals as scheduled by a Trickle algorithm. This is used to increase reliability of the method in case RF packets are lost.
  • the check for new-ness could be performed using known means e.g. a combination of original sender identity (i.e. the sensor node) and a sequence number in the event message (assigned by the sensor node).
  • a node completely reconstructs the event message based on the previous received event message. (This is e.g. useful if a different encryption has to be applied to the packet.)
  • the above tasks may be running fully or mostly at application level, i.e. the re-broadcasting function described is not necessarily integrated into a communications stack on the local node but can run as an application on top of the stack.
  • the re-broadcasting function described is not necessarily integrated into a communications stack on the local node but can run as an application on top of the stack.
  • using the API/facility of link-local UDP IPv6 multicast offered by a 6LoWPAN stack using the API/facility of link-local UDP IPv6 multicast offered by a 6LoWPAN stack.
  • Another alternative embodiment is equal to the above embodiment except that only “group members” (i.e. node devices in the destination group that the sensor node sends to) are configured to re-broadcast event messages. This slightly simplifies the configuration effort that is needed for the system. However, this means that for a specific type of message, the local instance of the routing entity used for routing this type of message is based on the group members, i.e. the neighboring node devices in the set of nodes listed in the global instance to which the node device belongs to.
  • a node i.e. device comprising a routing controller
  • a node has to perform the routing of packets in a local instance using a Frequency Hopping (FH) based method for wireless communication.
  • FH Frequency Hopping
  • routing in the global instance is performed in the way as described in other embodiments of this patent application.
  • local instance routing operations can be performed in the same way, thanks to the provisions of described in the embodiments below to keep multiple global instances synchronized in time with each other.
  • the RF frequency channel changes (‘hops’) based on an internal timer in each node.
  • the channel changes follow a known pseudo-random pattern called the hopping sequence, or channel sequence.
  • the pattern can be the same for all nodes or different per node. In any case, the pattern (or multiple patterns) is known to all nodes in a system.
  • time synchronization of the internal node timers is needed. To accomplish the time synchronization, there is usually a single node that acts as coordinator/Time Source and sends out time beacons that other nodes listen to sync their timer.
  • Time Source node Nodes that are out of reach of the Time Source node will time sync by receiving the time beacons of other nodes which send out time beacons based on their internal clock (but only if this clock has been synced already to time beacons of others). In this manner, a time beacon originating at the Time Source will “spread” throughout a mesh network covering all the nodes of the global instance.
  • Channel Index points to the current position in the channel sequence
  • Dwell timer indicates how much time has already been spent operating on the current channel.
  • the nodes 1, 2, 3 are each a Time Source for a single global instance.
  • the time beacons will spread to all nodes eventually through 1, 2 or 3 hops in the mesh.
  • the nodes A and B are both time-synchronized by the time beacons of their respective parent nodes as indicated by the arrow.
  • the Time Sources normally operate their internal timer without being synchronized to other clocks. There is also no need to have the internal timer synchronized to any other, because the time reference is only used within the boundaries of a single mesh network (global instance). In the situation of the embodiments of the invention, where local instance communication is needed, possibly across the boundaries of global instances, synchronization is required.
  • the nodes A and B in FIG. 5 need to communicate with neighbor nodes within their local instance, as represented by the dashed communication lines. This communication would not be possible if the nodes A and B are operating on different channels due to the Frequency Hopping. In a normal Frequency Hopping system, the internal timers of node 1 and 2 would not be synchronized hence nodes A and B most likely would operate on two different channels. Indeed, A derives its time reference—indirectly—from Node 1 and B indirectly—from Node 2.
  • FIG. 5 shows a conceptual sketch of the solution to keep multiple global instances synchronized in time using a GPS/GNSS absolute time reference.
  • each node is configured with a deterministic pseudo-random sequence, or function to calculate such sequences.
  • Each value in the sequence designates a frequency channel to operate in.
  • Each node e.g. 1,2,3 that is configured as a Time Source within a global instance enables its GPS receiver, from which an absolute time reference is obtained (such as GPS Time or UTC).
  • an absolute time reference such as GPS Time or UTC.
  • the border routers are preferably configured as Time Sources but in another variant, the Time Source could be included in another (or a plurality of) node(s) of the global instance.
  • Dwell timer value used to set an initial value for the Dwell timer.
  • the above variables are used to construct the time beacon signals; and other nodes per global instance synchronize to these time beacons as usual in FH systems.
  • nodes A and B are, at any time, able to communicate with each other on the same channel. This allows nodes to route packets over a local instance in the same way as described earlier in this patent application.
  • the accuracy of GPS Time that can be obtained in a low-cost node is sufficient to achieve the required accuracy (which is in the order of 0.5-100 ms, depending on the wanted performance of local instance communication and FH parameters used).
  • time pulse signal can be used.
  • the GPS module can be configured to generate a timing pulse on a wire, which is sampled on an input pin on the radio chip.
  • the radio chip can accurately calculate the two variables mentioned earlier (Channel Index and Dwell Timer) by using the following data in combination:
  • Reference Time e.g. UTC
  • Timestamp obtained from the GPS module via its serial API
  • Timestamp information provides the absolute time with some uncertainty (e.g. jitter due to serial communication or processing delays), which the time pulse transitions provide the information to correct for the inaccuracy.
  • time pulse signal will still be generated by the GPS module based on local clock if the GPS signal is temporarily lost. In this case the internal timer of the Time Source node will slowly drift away from the wanted Reference Time. Depending on crystal accuracy and ambient temperature changes, the timer in the Time Source node can remain good enough for our purposes for several minutes up to many hours.
  • Network Time Protocol is used.
  • This embodiment is similar to the embodiment of FIG. 5 , except that the Network Time Protocol (NTP) is used to derive the Reference Time instead of GPS.
  • NTP Network Time Protocol
  • This embodiment can be applied as a backup solution in case GPS signal is temporarily unavailable (e.g. due to weather conditions or blockage), or as a stand-alone solution (instead of GPS).
  • each Time Source regularly contacts a Time Server and runs a protocol (such as NTP) to synchronize its local timer with the Reference Time of the Time Server.
  • a protocol such as NTP
  • a time accuracy of 1-10 ms can be achieved, which is sufficient although communication performance is inferior to the GPS based method if the accuracy becomes larger than ⁇ 1 ms.
  • 2G/GPRS, 3G, 4G technologies the performance is expected to be worse.
  • 3G cellular one test shows that 10 ms accuracy can be achieved most of the time and 20 ms all of the time.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
US15/124,309 2014-03-13 2015-03-05 Method for configuring a node device, a network and a node device Active 2035-09-29 US10251073B2 (en)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
EP14159347 2014-03-13
EP14159347.5 2014-03-13
EP14159347 2014-03-13
EP14169879 2014-05-26
EP14169879.5 2014-05-26
EP14169879 2014-05-26
EP14176564 2014-07-10
EP14176564 2014-07-10
EP14176564.4 2014-07-10
PCT/EP2015/054553 WO2015135816A1 (en) 2014-03-13 2015-03-05 A method for configuring a node device, a network and a node device

Publications (2)

Publication Number Publication Date
US20170019804A1 US20170019804A1 (en) 2017-01-19
US10251073B2 true US10251073B2 (en) 2019-04-02

Family

ID=52627213

Family Applications (1)

Application Number Title Priority Date Filing Date
US15/124,309 Active 2035-09-29 US10251073B2 (en) 2014-03-13 2015-03-05 Method for configuring a node device, a network and a node device

Country Status (7)

Country Link
US (1) US10251073B2 (zh)
EP (1) EP3117664B1 (zh)
JP (1) JP6516105B2 (zh)
CN (1) CN106105319B (zh)
ES (1) ES2640905T3 (zh)
RU (1) RU2689428C2 (zh)
WO (1) WO2015135816A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11799751B2 (en) 2021-08-24 2023-10-24 Cisco Technology, Inc. Reclaiming transmission priority following network topology formation
US11974191B2 (en) 2020-01-02 2024-04-30 Signify Holding B.V. Method of and a node device for alerting node devices in a network of operatively interconnected node devices

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112135327A (zh) * 2015-09-23 2020-12-25 华为技术有限公司 一种报文处理的方法、网络设备及系统
JP6623802B2 (ja) * 2016-02-04 2019-12-25 ソニー株式会社 ユーザ端末、通信装置及び方法
US10320652B2 (en) * 2017-01-09 2019-06-11 Cisco Technology, Inc. Dynamic installation of bypass path by intercepting node in storing mode tree-based network
US10652036B2 (en) 2017-11-28 2020-05-12 Itron, Inc. Multi-network operation with member node for multicast groups
US10419231B2 (en) 2017-11-28 2019-09-17 Itron, Inc. Multi-network operation for multicast groups
US10491411B2 (en) 2017-11-28 2019-11-26 Itron, Inc. Limiting forwarding of multicast communications
WO2019108548A1 (en) * 2017-11-28 2019-06-06 Itron, Inc. Multi-network operation for multicast groups
US10812946B2 (en) 2018-02-22 2020-10-20 Cisco Technology, Inc. Reliable link layer multicast in a low power wide area network
CN110391923B (zh) * 2018-04-18 2021-03-30 华为技术有限公司 组播报文处理的方法以及网络设备
EP3606280B1 (en) * 2018-08-02 2022-10-05 Mitsubishi Electric R&D Centre Europe B.V. Method for managing a network and apparatus for implementing the same
US10958460B2 (en) 2018-09-26 2021-03-23 Itron, Inc. Connecting multiple networks for multicast groups
US11032094B2 (en) 2019-08-15 2021-06-08 Itron, Inc. Optimized multicast group forwarding
US11368525B2 (en) * 2019-12-02 2022-06-21 Red Hat, Inc. Relaying network management tasks using a multi-service receptor network
US11431518B2 (en) * 2020-02-13 2022-08-30 Cisco Technology, Inc. Localized multicast in a low power and lossy network based on rank-based distance
US11463350B2 (en) 2020-11-23 2022-10-04 Cisco Technology, Inc. Interconnecting local RPL instance nodes via global RPL instance node as AODV relay
CN114205889B (zh) * 2021-12-09 2023-10-20 中山大学 一种基于Zenoh的跨局域网分布式系统内通讯方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2004117074A (ru) 2001-12-03 2005-05-10 Нокиа Корпорейшн (Fi) Адресация и маршрутизация в беспроводных ячеистых сетях
US20070110063A1 (en) 2005-11-17 2007-05-17 International Business Machines Corporation Apparatus, system, and method for reliable, fast, and scalable multicast message delivery in service overlay networks
US20120230204A1 (en) 2011-03-08 2012-09-13 Cisco Technology Inc. Remote Stitched Directed Acyclic Graphs
US20120254338A1 (en) 2011-04-01 2012-10-04 Cisco Technology,Inc. Distributed control technique for rpl topology
WO2012140610A1 (en) 2011-04-15 2012-10-18 Koninklijke Philips Electronics N.V. Hierarchical routing for wireless networks
US20130028095A1 (en) * 2011-07-28 2013-01-31 Cisco Technology, Inc. Dynamic allocation of context identifiers for header compression
US20130227114A1 (en) 2012-02-28 2013-08-29 Cisco Technology, Inc. Hierarchical schema to provide an aggregated view of device capabilities in a network
JP2014120918A (ja) 2012-12-17 2014-06-30 Mitsubishi Electric Corp スマートメータシステム、管理ルータおよびメータ
US20170255785A1 (en) * 2014-09-15 2017-09-07 Philips Lightings Holding B.V. Method for communicating in a network comprising a virtual network , and a communication node comprising a virtual network entity

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101184047B (zh) * 2007-12-14 2012-07-25 华为技术有限公司 一种消息路由方法、设备及系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2004117074A (ru) 2001-12-03 2005-05-10 Нокиа Корпорейшн (Fi) Адресация и маршрутизация в беспроводных ячеистых сетях
US20070110063A1 (en) 2005-11-17 2007-05-17 International Business Machines Corporation Apparatus, system, and method for reliable, fast, and scalable multicast message delivery in service overlay networks
US20120230204A1 (en) 2011-03-08 2012-09-13 Cisco Technology Inc. Remote Stitched Directed Acyclic Graphs
US20120254338A1 (en) 2011-04-01 2012-10-04 Cisco Technology,Inc. Distributed control technique for rpl topology
WO2012140610A1 (en) 2011-04-15 2012-10-18 Koninklijke Philips Electronics N.V. Hierarchical routing for wireless networks
US20130028095A1 (en) * 2011-07-28 2013-01-31 Cisco Technology, Inc. Dynamic allocation of context identifiers for header compression
US20130227114A1 (en) 2012-02-28 2013-08-29 Cisco Technology, Inc. Hierarchical schema to provide an aggregated view of device capabilities in a network
JP2014120918A (ja) 2012-12-17 2014-06-30 Mitsubishi Electric Corp スマートメータシステム、管理ルータおよびメータ
US20170255785A1 (en) * 2014-09-15 2017-09-07 Philips Lightings Holding B.V. Method for communicating in a network comprising a virtual network , and a communication node comprising a virtual network entity

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
Ako Shindo et al, Proposal and Evaluation of a Scheduling Mechanism for RPL-based Service Network Multiplexing, The Institute of Electronics, Information and Communication Engineers, JEICE Technical Report IN2013-3 (Apr. 2013) pp. 13-18.
Gen Xu et al, "Multipath Routing Protocol for DAG-Based WSNs With Mobile Sinks", Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering (ICCSEE 2013), pp. 1678-1682.
Hiroshi Matsura, "Proposal of Multi-DODAG RPL Management System", Proceedings of the 2014 IECE General Conference, ISSN 1349-1369, Mar. 18-21, 2014, Niigata Univ., Niigata, pp. 1-5.
Internet Engineering Task Force, IETF; Standard; 26 March 2012 (2012-03-26), T. WINTER, ED. P. THUBERT, ED. CISCO SYSTEMS A. BRANDT SIGMA DESIGNS J. HUI ARCH ROCK CORPORATION R. KELSEY EMBER CORPORATION: "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks; rfc6550.txt", XP015081473, Database accession no. 6550
Jonathan Hui et al, RPL: The IP Routing Protocol Design for Low Power and Lossy Networks; IEEE Draft; RPL, IEEE-SA, Piscataway, NJ USA, vol. MSC.UPAMD, Sep. 9, 2011, pp. 1-20, XP068029364.
JONATHAN HUI, SOFTWARE ENGINEER, CISCO SYSTEMS ZACH SHELBY, CHIEF NERD, SENSINODE PAUL BERTRAND, FOUNDER, VP, WATTECO SAS: "RPL: The IP routing protocol designed for low power and lossy networks ; RPL", IEEE DRAFT; RPL, IEEE-SA, PISCATAWAY, NJ USA, vol. msc.upamd, RPL, 9 September 2011 (2011-09-09), Piscataway, NJ USA, pages 1 - 20, XP068029364
Pinney, T. et al "RPL Applicability in Industrial Networks Draft-IETF-Roll-RPL-Industrial-Applicability-02"; Internet Engineering Task Force, IETF, Standardworking, Internet Sociey (ISOC) 4, Rue Des Falaises CH-1205 Geneva, Switzerland, Oct. 21, 2013, pp. 1-31, XP015095666.
T. PHINNEY, ED. CONSULTANT P. THUBERT CISCO RA. ASSIMITI NIVIS: "RPL applicability in industrial networks; draft-ietf-roll-rpl-industrial-applicability-02.txt", RPL APPLICABILITY IN INDUSTRIAL NETWORKS; DRAFT-IETF-ROLL-RPL-INDUSTRIAL-APPLICABILITY-02.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, draft-ietf-roll-rpl-industrial-applicability-02, 21 October 2013 (2013-10-21), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland, pages 1 - 31, XP015095666
T. Winter et al, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks; RFC6550, Internet Engineering Task Force, IETF; Standard Internet Society 4, Rue Des Falaises CH-1205 Geneva, Switzerland, Mar. 26, 2012, pp. 1-157, XP015081473.

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11974191B2 (en) 2020-01-02 2024-04-30 Signify Holding B.V. Method of and a node device for alerting node devices in a network of operatively interconnected node devices
US11799751B2 (en) 2021-08-24 2023-10-24 Cisco Technology, Inc. Reclaiming transmission priority following network topology formation

Also Published As

Publication number Publication date
CN106105319B (zh) 2020-03-03
EP3117664B1 (en) 2017-06-28
RU2689428C2 (ru) 2019-05-28
EP3117664A1 (en) 2017-01-18
US20170019804A1 (en) 2017-01-19
JP2017510190A (ja) 2017-04-06
WO2015135816A1 (en) 2015-09-17
RU2016140124A3 (zh) 2018-10-29
CN106105319A (zh) 2016-11-09
RU2016140124A (ru) 2018-04-13
JP6516105B2 (ja) 2019-05-22
ES2640905T3 (es) 2017-11-07

Similar Documents

Publication Publication Date Title
US10251073B2 (en) Method for configuring a node device, a network and a node device
RU2419230C2 (ru) Способ и устройство для обнаружения соседних узлов с поддержкой конечными узлами
US20170055236A1 (en) Multiple access point wireless mesh network
JP5430481B2 (ja) ゲートウエイおよび端末
CN102550005B (zh) 利用对等无线网络中的良好连接的节点的方法和系统
US20160380778A1 (en) A Master Device and Methods Therein
CN109547348B (zh) 一种通信、路由建立方法和装置
KR20080087850A (ko) 물리적 접속점 식별자를 사용한 통신 방법 및 장치
EP1683308B1 (en) Method and apparatus for route discovery within a communication system
Zirak et al. Swarm of drones using LoRa flying Ad-Hoc network
Soleimani et al. D2D scheme for vehicular safety applications in LTE advanced network
WO2015071846A1 (en) Operating a user equipment in a wireless mesh radio network
EP3939370A1 (en) Receiver-centric communication by combined network technologies for enhanced reliability
Le Sommer et al. Location-Aware Routing for Service-Oriented Opportunistic Computing
US11757770B2 (en) Hybrid ad-hoc routing protocol
Sujatha et al. Greedy perimeter stateless routing in MANET's
Al-Shehri et al. Localization Enhanced Mobile Networks
Noureddine et al. FORTEL: Forecasting routing technique using location information for Mobile Ad hoc networks
Mishra et al. Position based routing protocols: A survey
Kalpana et al. Enhanced Energy Efficient Routing for Self Adapive Geographic Routing In Manet’s
Sucec et al. Capacity compatible 2-level link state routing for ad hoc networks with mobile clusterheads
John et al. A Novel Approach for Improving the Performance of Geographic Routing in MANET using OGRP

Legal Events

Date Code Title Description
AS Assignment

Owner name: KONINKLIJKE PHILIPS N.V., NETHERLANDS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MORCHON, OSCAR GARCIA;SHARMA, SAHIL;DE LA VEGA RUIZ, ALFONSO;AND OTHERS;SIGNING DATES FROM 20150307 TO 20160909;REEL/FRAME:041160/0098

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: SIGNIFY HOLDING B.V., NETHERLANDS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KONINKLIJKE PHILIPS N.V.;REEL/FRAME:049713/0510

Effective date: 20160201

AS Assignment

Owner name: SIGNIFY HOLDING B.V., NETHERLANDS

Free format text: CHANGE OF NAME;ASSIGNOR:PHILIPS LIGHTING HOLDING B.V.;REEL/FRAME:050837/0576

Effective date: 20190201

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4