Classifications

• • 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/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
• • 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/02—Topology update or discovery
• • 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
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/18—Loop-free operations
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D30/00—Reducing energy consumption in communication networks
  • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

• the invention is in the context of multicast multicasts in computer networks with high constraints in terms of available resources (batteries, memories, computing capacities, links available, etc.) and more specifically concerns a method for preselecting a router in a LLN (Lower Power and Lossy Network) network among a plurality of nodes that can act as data packet routers exchanged between a plurality of host nodes, said LLN network having a root node responsible for managing a first data table; an association containing a list of router nodes authorized to transfer multicast packets from the LLN network to a given host node or from a given host node to the LLN network, each router node having a status from one of the following statuses:
• LLN Lower Power and Lossy Network
• the invention also relates to a device for implementing the method according to the invention and a program stored on a recording medium and comprising instructions for implementing the steps of the method when it is exercised on a computer.
• LLN Lower Power and Lossy Network
• Duplication of data packets exchanged during multicast communications in LLN (Lower Power and Lossy Network) type networks has the effect of wasting resources such as bandwidth, computing capacity, space memory and the energy reserve which are very limited in this type of networks. This waste can cause a major network malfunction, premature aging or even complete blockage.
• This problem occurs when a multicast packet is transmitted / broadcast in a level 2 frame corresponding to the logical link control sublayer of the Open System Interconnection (OSI) model; for example broadcast-type Media Access Control (MAC), which is often the case in computer networks including LLNs networks.
• OSI Open System Interconnection
• MAC Media Access Control
• the duplicate packets may come from a node that broadcasts multicast data packets without respecting the transfer logic of a RPL node. that is, without transferring the multicast packet in a unicast (level 2) frame to one or more neighboring node (s) determined.
• RPL Routing Protocol for Low Power and Lossy Networks
• the node in question is in radio range of a network RPL but is not part of the network itself. This situation corresponds to the case where the node has no information on the nodes of the RPL network, or does not use the functionalities of this type of network.
• Such a node may be, for example, a node without battery recovering the energy necessary for the transmission of a message, for example a command, through an external physical action undergone by the node such as a ZigBee type node GreenPower (wireless switch and without battery).
• a ZigBee type node GreenPower wireless switch and without battery.
• a multicast source In the case of a multicast source, it can send a multicast IP packet on a Broadcast level 2 frame that will be received by all RPL routers in direct radio range of this source. If it is a multi-hop multicast packet, close-to-near transmission will be performed until the packet reaches its final destination. However, if the IP multicast packet sent by the source is received by several RPL routers in direct radio range of said source, each of these routers will transmit in the network a copy of said packet. This situation is then at the origin of duplication of said packet in the RPL network since this same packet is injected simultaneously and independently into the RPL routing tree by several nodes.
• a node on the path of the packets which may be either an intermediate router or the final destination of the packets, may receive several copies of the same multicast packets, which can cause a number of problems such as for example over-consumption of the band passing through the network or its premature aging.
• a packet destination node is similar to that of the source in terms of effects on the network, except that the purpose of the destination node is to receive multicast packets and not to transmit them.
• the destination node transmits in broadcast (level 2) its membership request to an IP multicast group in an RPL network, for example an MLD report type request ([R. Vida et al., Multicast Listener Discovery "Version 2 (MLDv2) for IPv6", RFC 3610, June 2004]).
• MLDv2 Multicast Listener Discovery "Version 2 (MLDv2) for IPv6", RFC 3610, June 2004]
• any RPL router having received said request will initiate the construction of a routing path consisting of a branch of a multicast tree from the RPL network to the destination node.
• the receiving node may receive as many copies of the same multicast IP packet as there are RPL routers within its direct reach. Again this duplication of traffic in the RPL network can cause many problems such as over-consumption of network bandwidth or premature aging.
• multiple nodes may simultaneously apply to act as a multicast router for a given host node. This results in a large number of requests for applications sent to the root node for this purpose. This also results in over-consumption of the bandwidth and a large processing load of the requests by the root node.
• the object of the invention is to overcome the disadvantages of the prior art described above by means of a so-called "local" election method concerning the RPL router nodes in direct radio range of a source or a a receiver allowing these RPL router nodes to decide which will transmit to the root node a MER_Request message to serve as a single multicast router for a host node, source or multicast data receiver, and possibly for a given multicast group.
• This method aims to reduce the number of RPL nodes that will be candidates for the election of a multicast router for a given host node in the RPL network.
• Another objective of the invention is to define a local procedure, called the application selection procedure, which makes it possible to automatically choose the candidate nodes to send a MER_Request request to the root node, these candidates possibly being nodes that are not in direct range of a host (source or receiver).
• This object is achieved by means of a method of preselecting a router in a LLN (Lower Power and Lossy Network) network among a plurality of nodes that can act as routers of data packets exchanged between a network.
• LLN Lower Power and Lossy Network
• plurality of host nodes said LLN network having a root node responsible for managing a first association table containing a list of router nodes authorized to transfer multicast packets from the LLN to a given host node or from a given host node to the host node.
• LLN network each router node having a status of one of the following statuses:
• CANDI DAT_MER Multicast Edge Router
• NON_MER indicating that said router node is configured not to be a multicast router for said host node.
• the process according to the invention comprises the following steps:
• said router node upon receipt by a given router node of a multicast data packet or subscription request to a multicast group (eg, Multicast Listener Discovery Report (MLD) message) from a node given host, said router node transmits to the other router nodes of the LLN network its direct radio range an announcement message including its status vis-à-vis the host node and the address of said host node.
• MLD Multicast Listener Discovery Report
• each of said other router nodes compares its current status with respect to said host node to the status indicated in the announcement message, and configures its status according to said compa reason so that a single node among the LLN network nodes in direct radio range of said router node transmits to the root node a configuration MER_Request request as a multicast router for the data from or to said given host node, and
• the root node upon reception of said MER_Request, grants the MER status for said host node to the first router node that has transmitted a MER_Request.
• each router node stores routing information in a second association table in the following fields:
• a "host address” field to contain the address of the host node
• An optional "host type” field intended to contain the type of said host node from one of the following two types, source or receiver;
• An optional "multicast IP address” field to contain the address of a multicast group to which the host node belongs;
• a "status” field intended to contain the status of the router node vis-à-vis said host node, and can take one of four values: CANDIDATJV1ER, PENDING, MER and NON_MER;
• a "Lifetime_table_entry" field intended to contain a lifetime of the input associated with the host node in said second association table, i.e. a lifetime of the status of the router node vis-à-vis said host node;
• any optional field of the MER_Request / MER_Reply messages and association tables will be designated by [X], where X represents the name of the optional field.
• These optional fields are: host node type and multicast IP address.
• a router node when a router node receives said announcement message, it first checks in said second association table if one of its entries corresponds to the address fields of the host, [host type], and [multicast IP address] of the received announcement message, and if the check returns no input, said router node will ignore the received advertisement message.
• the router node compares its address to that of the router node sending the announcement message, and, keeps its status CANDIDAT_MER if its address is lower than that of the sending router node of the announcement message, or sets the status associated with the entry found to NON_MER if its address is greater than the address of the sending router node of the message of ad.
• the advertisement message contains a CANDI status DAT_MER and said second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type] , and [multicast IP address] contained in the received announcement message, and if such an entry has a PENDING status or a NON_MER status, or an MER status for said router node vis-à-vis the host node identified in the announcement message, the latter ignores the received announcement message.
• said router node can respond to the router node that sent said announcement message by another advertisement message containing a MER status associated with the address fields of the host, [type of the host], and [multicast IP address] of said input.
• announcement message contains a MER status and the second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type], and [address IP multicast] contained in the received announcement message, and,
• said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message so as to synchronize the value of the field [lifetime_table_entry] at all the routers nodes having the entry found,
• said router node replaces the value of the field lifetime_table_entry associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
• said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
• said router node may ignore the received message.
• the announcement message contains a NON_MER status and the second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type], and [address IP multicast] contained in the received announcement message, and if such an entry indicates a MER status, said router node ignores the received message,
• said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message,
• said router node replaces the value of the field lifetime_table_entry associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
• said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER. Alternatively, said router node may ignore the received message.
• the router node that has received the request to subscribe to a multicast group (eg the MLD Report message) checks whether exists in said second association table a host node concerned by the message of MER_Reply response received, and, if so, sets its status to the relevant host node to NON_MER, and replaces the value of the lifetime_table_entry field with the one specified in the received MER_Reply message
• the router node In the case where the router node receives a MER_Reply response message from the root node having an MER status, said router node checks whether there exists in the second association table a host node concerned by the received MER_Reply message, if it is the case, it puts its status vis-à-vis the relevant host node to MER, and, replaces the lifetime of its status vis-à-vis said host node by that indicated in the MER_Reply message received (ie. d replaces the value of the lifetime_table_entry field with the value specified in the received MER_Reply message), establishes a multicast branch in the network going to the host node, and broadcasts in multicast with local scope an advertisement message with the MER status.
• a host node concerned by the received MER_Reply message if it is the case, it puts its status vis-à-vis the relevant host node to MER, and, replaces the lifetime of its status vis-à-vis said host node by that
• the advertisement transmitted by the router node is implemented through a DIO type message of the RPL (DODAG Information Object) protocol.
• RPL DODAG Information Object
• said router node stores the multicast data packet received if its memory allows it.
• the router node transfers the received packet to the multicast tree; and, if said status is NON_MER, the router node ignores the received multicast packet.
• said router node also stores the multicast data packet received if the memory allows it.
• said node router checks whether there exists in its association table a host node concerned by the received MER_Reply response message.
• said router node sets its status to the relevant host node to NON_MER, replaces the value of the lifetime_table_entry field with the one specified in the received MER_Reply message, and removes from its memory any multicast data packet. associated with said previously stored entry.
• the router node which has received the MER_Reply message configuring it with the MER status for said entry in its second association table can transmit into the network any multicast data packet associated with said previously stored entry as well as any packet of received future multicast data corresponding to said input.
• LLN Lower Power and Lossy Network
• LLN Lower Power and Lossy Network
• ⁇ CANDIDAT_MER Multicast Edge Router
• each router node transmits to the other nodes of the LLN network in direct radio range of said host node an announcement message comprising information having a value on the basis of which will be conducted the configuration of the router nodes as CANDI DAT_MER or N 0 N_C AN DID AT_M ER, said information being able to be contained in the data field of the announcement message (eg a given value) or else in a header of the announcement message (e.g. MAC address or the source IP address of the router node issuing the announcement).
• each of said other router nodes compares the value of its own information (eg MAC address or IP address or other information used for the configuration of the states C AN DID AT_M ER / N 0 N_CAN DID AT_M ER of a router node) to that contained in the announcement message, and, if the value of the information contained in the announcement message is less than the value of the information of the router node having received said announcement message, then the latter goes into the state NON_CANDIDAT_MER, otherwise, the router node that received said announcement message remains in the state CANDIDAT_MER.
• its own information eg MAC address or IP address or other information used for the configuration of the states C AN DID AT_M ER / N 0 N_CAN DID AT_M ER of a router node
• this pre-selection is not necessarily conditioned on the reception by a router node of a request to subscribe to a multicast group (for example an MLD Report message) or a multicast message from a node. given host (receiver or source).
• the pre-sectioned MER candidate ie in the CANDIDAT_MER state
• the source address (eg MAC address or IP address) of the announcement messages (eg DIOs of the RPL protocol) exchanged between the RPL routers is used to allow each RPL router to decide whether it has the right to be a candidate router (ie in the CANDIDAT_MER state), and therefore to later contact the root node via MER_Request messages to determine if it will be configured by the latter as a single multicast router (ie with MER status) to a given host node.
• each router node having a status NON_CANDIDAT_MER comprises a transfer table for managing the exchanges of multicast packets between a router node and a host node, said transfer table comprising the following fields :
• the host address field to contain the host node address
• MAC_x address intended to contain the MAC address of the node from which the multicast packet was received or the MLD Report message
• the "MAC_y address” field intended to contain the MAC address of the CANDIDAT_MER (not applicable if the current RPL router is itself CANDI DAT_MER) ⁇
• the Lifetime_table_entry field intended to contain a lifetime of the input associated with the host node in said transfer table;
• any optional field of the transfer table will be designated by [X] where X represents the name of the optional field.
• These optional fields are: host node type and multicast IP address.
• each router node comprises an announcements table containing neighboring routers from which it has received an announcement message, so that each time a router node NON_CANDIDAT_MER receives an announcement message of a new router node that is not already listed in its advertisement table, said router NON_CANDIDAT_MER adds the MAC address of said new router node to its advertisement table, compares the MAC address of the new router node to the address MAC of the current router node CANDIDAT_MER indicated in its table of announcements, and if the IP address of the new router node is lower than that of the current node CANDIDAT_MER, said router node NON_CANDIDAT_MER considers that it is the new node router which is its new CANDIDAT_MER and update its table of announcements accordingly.
• a router node when a router node receives a subscription request to a multicast group (for example a message of the MLD Report type) from a receiver-type host node, it consults its second table. association to check if it has already received the same subscription request and, ⁇ If it is, the request (eg the message MLD report) is ignored,
• ⁇ stores the message received in the subscription request if it is in the CANDIDAT_MER state and if memory allows it, translates this message into a MER_Request message, then transmits said MER_Request message to the root node; on the other hand, if it is in the state NON_CANDIDAT_MER, it transfers said message to the node CANDIDAT_MER indicated in its table of announcements.
• the first variant of the method according to the invention is implemented by a device in which each router node is adapted to transmit to the other router nodes of the LLN network in direct radio range of said host node an announcement message including its status vis-à-vis -vis a host node and the address of said given host node and each of said other router nodes is adapted to compare its status vis-à-vis said given host node to the status indicated in the announcement message, and to configure its status according to said comparison so that a single node among the LLN network nodes in direct radio range of said host node transmits to the root node a configuration MER_Request request as a multicast router for said given host node; said root node being adapted to grant the MER status for the given host node to the first router node that has sent it a MER_Request.
• each router node is adapted to transmit to the other router nodes of the LLN network in its direct radio range an announcement message comprising information (e.g. the MAC address or the source IP address of the router node transmitting the advertisement or any other information) having a value on the basis of which the configuration of the router nodes will be conducted as CANDIDAT_MER or NON_CANDIDAT_MER, and each of the other nodes routers is adapted to compare the value of its own information (eg MAC address or IP address or any other information used for the configuration of the C AN DID AT_M ER / N 0 N_CAN DID AT_M ER states of a router node) to that contained in the announcement message, so that if the value of the information contained in the announcement message is less than the value of the information of the router node having received said announcement message, then it goes into the state NOT_CAN DIDAT_MER, otherwise, it remains in the state CANDI DAT
• the method according to the invention is implemented by a computer program stored on a recording medium and having instructions for carrying out the steps of the first variant or the second variant when it is executed on a computer.
• FIG. 1 illustrates the message exchange sequence between RPL nodes, data packet source host nodes, and the root node for the selection of a multicast router in an RPL network according to the invention
• FIG. 2 illustrates the message exchange sequence between RPL nodes, host nodes receiving data packets, and the root node for selecting a multicast router in an RPL network according to the invention.
• FIG. 3 schematically illustrates the preselection steps of a router node in a particular variant of the method according to the invention.
• the root node 4 includes a first table, called association table, for storing associations between at least one of the host nodes respectively referenced 6 and 8 of a multicast group and one of the RPL nodes.
• a host node that can be either the source or the recipient of the data packets exchanged across the network. In the rest of the description, identical references will designate elements fulfilling identical functions in the different figures.
• a source host node of data packets will be designated by the source term 6, and a receiving host node of data packets by the term receiver 8.
• the LLN network to which reference will be made later in this description comprises only two router nodes 2 and 3 in direct range of the host nodes 6 and 8.
• the method according to the invention also applies in the where the network has more than two RPL nodes.
• the configuration of an RPL node is performed by exchanging MER_Request / MER_Reply configuration messages between the root node 4 and each RPL node that has requested to serve as a multicast router vis-à-vis a given host node.
• the elected RPL node is referred to as the Multicast Edge Router or Multicast Edge Router for a source or receiver.
• the MER will be in charge of intercepting multicast packets from the source and transmitting them in the RPL multicast broadcast tree.
• the MER will be in charge of intercepting the multicast membership requests of this receiver, such as for example a request of the type MLD report (for Multicast Listener Discovery described in
• MLDv2 Multicast Listener Discovery Version 2
• the exchange of MER_Request / MER_Reply messages is implemented through an extension of the exchange.
• DAO / DAO_ACK of the RPL protocol.
• the RPC Protocol's Destination Warning Object (DAO) message is traditionally used by RPL nodes to add or remove a branch (an IP path) from the RPL network.
• the message DAO_ACK is sent from the root node 4 to the RPL node 8 in response to a DAO message.
• DAO Destination Warning Object
• each RPL node can have one of the following statuses: ⁇ CANDIDAT_MER (Multicast Edge Router), indicating that the router node is a candidate to act as a single multicast router for a given host node;
• ⁇ CANDIDAT_MER Multicast Edge Router
• ⁇ MER indicating that said router node is configured as a single multicast router for said host node
• ⁇ Host Address The IP address of a multicast source or receiver
• Host type optional field specifying the type of the host, or the type can be "source” or “receiver”;
• ⁇ Multicast address optional field specifying the multicast group address associated with the source or receiver
• Lifetime / lifetime the lifetime of the host-associated input
• FIG. 1 illustrates the message exchanges between the root node 4 and two RPL nodes 2 and 3 for the election of an MER from these two nodes for the source 6.
• step 20 the source 6 broadcasts a multicast data packet comprising, in addition to the payload data, a header indicating the address of the source @S and the multicast address mcast @ of the group to which the destination node of the packet of data.
• each of the RPL nodes 2 and 3 Upon reception of the broadcast packet, each of the RPL nodes 2 and 3 determines that it has no entry in its said second association table corresponding to the received message and thus generates a new entry for said host node (indicating the host address and optionally the host type and multicast address), assign the CANDIDAT_MER status to this entry, assign non-zero values Lifetime_statut and Lifetime_table_entry fields respectively, and stores the received multicast packet if its available memory allows it. Each of the RPL nodes 2 and 3 also generates an announcement message including its status vis-à-vis the source 6 and the address of said host node (ie CANDI DAT_MER).
• step 22 the RPL node 2 (respectively 3) transmits the generated advertisement message to the node RPL 3 (respectively 2).
• step 26 the RPL node 2 verifies that the status of the RPL node 3 indicated in the announcement message is CANDIDAT_MER, compares its address to that of the RPL node 3, and keeps its CANDI DAT_MER status if its address is lower. to that of RPL node 3.
• step 27 the RPL node 3 verifies that the status of the RPL node 2 indicated in the announcement message is CANDIDAT_MER, compares its address to that of the RPL node 2, and changes its status to NON_MER, and empty of its memory the stored multicast data packet (s), if its address is greater than that of the RPL node 2.
• step 28 the Lifetime_statut field of said RPL 2 association table entry expires and the RPL node 2 sets a PENDING value to its status for said entry.
• step 36 the elected node RPL 2 puts its status vis-à-vis the source at MER, and replaces the value of the field lifetime_table_entry with that indicated in FIG. received MER_Reply message, transfers the multicast data packet (s) received from the source 6 to the multicast tree, and then empties its memory.
• step 40 the RPL node 3 updates the value of the field [lifetime_table_entry].
• the RPL node 2 Upon receiving a new multicast data packet from the source 6 (step 42) the RPL node 2 automatically transfers (step 44) the data packet to the multicast tree, while the RPL node 3 ignores this new packet (step 46).
• FIG. 2 illustrates the message exchanges between the root node 4 and two RPL nodes 2 and 3 for the election of a MER from these two nodes for the receiver 8.
• the receiver 8 broadcasts an adhesion message to a multicast group (eg a message of the MLD Report type) comprising the address of the receiver 8 and the IP address mcast @ of the multicast group to which belongs the recipient 8.
• a multicast group eg a message of the MLD Report type
• the RPL node 2 Upon receipt of the multicast group membership message (eg, an MLD message), the RPL node 2 (respectively RPL 3) determines (step 52) (respectively 54) that it has no entry in the multicast group. its so-called second association table corresponding to the received message and thus generates a new entry for said host node (by indicating the address of the host and optionally the type of the host (receiver) and the multicast address), assigns the CANDIDAT_MER status to this entry, assigns non-zero values to the Lifetime_statut and Lifetime_table_entry fields respectively, and stores the received membership message if available memory permits.
• the multicast group membership message eg, an MLD message
• Each of the RPL nodes 2 and 3 also generates an announcement message including its status vis-à-vis the addressee 8 and the address of said host node 8 (ie CANDI DAT_MER).
• the RPL node 2 (respectively RPL 3) transmits the generated advertisement message to the node RPL 3 (respectively 2).
• step 60 the RPL node 2 (respectively RPL 3) checks the status of the RPL node 3 (respectively RPL 2) indicated in the announcement message, compares its address to that of the RPL node 3 (respectively RPL 2) and, keep its status CANDI DAT_MER if its address is lower than that of the node RPL 3 (respectively RPL 2) and if the status of the node RPL 3 is CANDIDAT_MER.
• the @ R1 address of the RPL node 2 is less than that of the RPL node 3. In this case, the latter sets its status to NON_MER, whereas the RPL node 2 retains its CANDIDAT_MER status. .
• step 64 the Lifetime_statut field of said RPL 2 association table entry expires and the RPL node 2 sets a PENDING value to its status for said entry.
• step 66 the RPL node 2 transmits to the root node 4 a MER_Request request including the address of the recipient 8, and optionally the type of this recipient and the address of the multicast group to which this recipient belongs.
• the root node checks whether the node RPL 2 is the first node having transmitted a request MER_Request, and if it is the case, grants the status MER to this node and transmits it (step 70) a response MER_Reply having said MER status, the recipient address 8, and optionally the type of this recipient 8 and the address of the multicast group to which this recipient belongs, and a non-zero value for the Lifetime_table_entry field of the RPL node 2 vis-à-vis -vis the recipient 8.
• step 72 the elected RPL node 2 sets its MER status to replace the value of the lifetime_table_entry field by the one specified in the received MER_Reply message, and creates a branch of the multicast tree, and then empties its memory.
• the RPL node 2 broadcasts, in multicast with local scope, an advertisement message including the MER status, the address of the recipient 8, and optionally the type of the recipient 8 and the multicast IP address of the group. to which this recipient 8 belongs, as well as the lifetime of the entry (lifetime_table_entry) so that the RPL 3 node can update the value of the field lifetime_table_entry based on the one indicated in the announcement message sent by the RPL node 2.
• the RPL node 3 updates the value of the lifetime_table_entry field.
• FIG. 3 illustrates the steps of a second variant of the invention making it possible to preselect a subset of router nodes among a set of nodes having a status among one of the following statuses, CANDIDAT_MER or NON_CANDIDAT_MER.
• any RPL node (CANDIDAT_MER or NON_CANDIDAT_MER) stores in its memory the MAC address of the node from which it has received a new multicast packet or a new MLD Report.
• any router NON_CANDIDAT_MER stores in its memory the MAC address of its router CANDIDAT_MER.
• each router RPL NON_CANDIDAT_MER is supposed to manage a specific table, called transfer table for transferring the multicast packets from the MER to the receiver and to filter and transfer the multicast packets from the source to the MER.
• the transfer table at an RPL router contains the following elements:
• Host type optional field specifying the type of the host, or the type can be "source” or “receiver”,
• ⁇ Multicast address optional field specifying the multicast group address associated with the source or receiver
• ⁇ MAC_x address MAC address of the node from which the multicast packet or the MLD Report was received
• each RPL node has an announcement table containing neighboring routers from which it has received an announcement message so that each time a NON_CANDIDAT_MER router receives an announcement message from a new router that does not is not in its announcement table, said router NON_CANDIDAT_MER adds the MAC address of said new router in said announcement table.
• RPL node called A when initialized, it sets its status to "CANDI DAT_MER" (step 80) and remains in this state until its status is obsolete by certain conditions mentioned below.
• the RPL node A When the RPL node A then receives (step 82) an announcement message such as, for example, a DIO message of the RPL protocol sent in multicast with a local scope by another router RPL called router B, said router A compares (step 84) its address. @A to RPL router B. @B address
• router "A" goes into the NON_CANDIDAT_MER state (step 86) and adds the @B address in its announcements table indicating that the router B is CANDI DAT_MER from the point of view of the router A (step 87). Otherwise, router A remains in the CANDIDAT_MER state.
• router A checks if @B already exists in its announcement table.
• router A ignores the announcement sent by Router B (step 90).
• router A adds the @B address in its ads table
• each router in the RPL network can decide whether it has the right to be a candidate router (and therefore to contact the root node for this purpose via MER_Request messages).
• the CANDI router DAT_MER is not always in direct radio range of the source.
• the method according to the invention is applicable both in the context of low power / lossy networks (LLNs), for example wireless sensor networks, as well as in multicast IP telecommunications networks thanks to: "the definition of a mechanism for exchanging messages in the network
• RPL between a set of routers and a root node; the exchange allowing the root node to designate a multicast router to serve a multicast source or a multicast receiver (ie accept / forward a multicast packet from a multicast source or send a multicast packet to a multicast receiver) ;
• Feature definition specifying the conditions for selecting a multicast router (MER) at the root node
• the present invention applies regardless of the routing mode of the multicast traffic used in the RPL network; that it is in particular the so-called mode “multicast storing” as defined by the specification RPL or the mode called “multicast non-storing” defined in [CJanneteau, M. Kellil, BD12830 "Method of routing a flow in non-storage mode ", French patent application filed on July 11, 2011 under No. 11 56273].

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Small-Scale Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=47780076

Family Applications (1)

Country Status (4)

Families Citing this family (12)

Family Cites Families (7)

• 2012
  • 2012-03-07 FR FR1252077A patent/FR2987964B1/fr not_active Expired - Fee Related
• 2013
  • 2013-03-05 EP EP13707177.5A patent/EP2823609A1/de not_active Withdrawn
  • 2013-03-05 WO PCT/EP2013/054316 patent/WO2013131867A1/fr active Application Filing
  • 2013-03-05 US US14/383,356 patent/US20150304118A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events