Smf-type communication method for a manet network, network node and mobile network which implement this communication method

This communication method is hereinafter described with reference, purely by way of example, to the mobile telecommunications network 1 shown in Figure 1, which is a wireless packet network and includes a plurality of nodes 2, which are at least potentially mobile and communicate with each other by means of electromagnetic signals. Always by way of example, it is assumed that the nodes 2 are part of a multicast-type group 4 and that the mobile telecommunications network 1 also comprises a plurality of external nodes 6, which are not part of the group 4. Without any loss of generality, it is assumed that the nodes 2 and the external nodes 6 are all alike; the mobile telecommunications network 1 is therefore a peer-to-peer mesh-type MANET network.

For the purposes of this communication method, it is irrelevant how membership of the nodes 2 to group 4 has been determined and coded.

For example, the group 4 may be of the static type, in which case, the information regarding the membership of the nodes 2 to the group 4 and the information regarding the non-membership of the external nodes 6 to the group 4 may be preconfigured, in a manner which is in itself known, inside the nodes 2 and the external nodes 6.

Alternatively, the group 4 may be of the dynamic type, in which case, in a manner that is in itself known, the nodes may manage the group by the implementation, in the respective protocol stacks, of a protocol of the type, for example, such as the Internet Group Management Protocol (IGMP), described, for example, at Internet address https://datatracker.ietf.org/doc/rfc3376. In order to manage the group, it is also possible that a specific notification is introduced, in order to notify the start and end of participation of any node in the group 4.

3914450

Date Reçue/Date Received 2020-04-28

For example, the entry of a node 2 in the group 4 may be notified by the same node 2 through the broadcast transmission of a corresponding control packet, which shall hereinafter be referred to as the entry packet.

The entry packet contains a group address that identifies the group 4, as well as a progressive sequence number, which is incremented by one unit on each transmission of an entry packet. In the case (not shown) where the mobile telecommunications network 1 contains more than one group, the entry packet contains the addresses that identify all the groups that the node enters, which are also referred to as group addresses.

On the basis of the entry packets received, each node keeps a group table up to date, in which it stores, for each group, the corresponding group address and the addresses of the member nodes. In particular, the updating of the group table may take place through the introduction, for each data item contained therein, of a validity timeout, with the deletion of the data upon expiration. Alternatively, it is possible that each node, when it leaves a group, transmits a corresponding exit packet, through which it notifies the other nodes of it leaving the group.

For greater clarity, hereinafter the nodes 2 are also referred to as group nodes 2. In addition, special reference is made to a source node S, which, purely by way of example, belongs to the group 4. In addition, reference is made to first and second relay node RI and R2, which are neighbours of the source node S and are multipoint relays of the source node S, as well as a first and second block nodes Bl and B2, which are both two hops away from the source node S and are neighbours, respectively, of the first and second relay nodes RI and R2. More in particular, the first relay node RI and the first and

3914450

Date Reçue/Date Received 2020-04-28 second block nodes Bl and B2 do not belong to the group 4, while the second relay node R2 belongs to the group 4;

furthermore, the first block node Bl is a multipoint relay of the first relay node RI, while the second block node B2 is a multipoint relay of the second relay node R2.

Without any loss of generality, it is also assumed that the nodes perform this communication method on the Internet Protocol (IP) layer, and that therefore the traffic, i.e. the control packets and data packets, are of the IP type. In this case, when a node generates (and consequently transmits) a packet, it inserts its IP address, as well as its address related to a lower layer, such as its address in the Media access control (MAC) Ethernet address format for example. Furthermore, when a generic node retransmits a packet, it does not change the IP address of the packet, which indicates the node from which the packet originated, but inserts its own MAC address, replacing the previously stored MAC address. Therefore, except where specified otherwise, and without any loss of generality, it is assumed that the addresses mentioned hereinafter are IP addresses.

That having been said, assuming that the source node S generates a data packet addressed to the group 4, i.e. addressed to all the other group nodes 2, it transmits the data packet so that the data packet is received and processed by all the neighbouring nodes of the source node S. The data packet generated by the source node S contains the group address of the group 4.

Given any other node of the mobile telecommunications network 1 that i) receives the data packet transmitted by the source node S and is a multipoint relay of the source node S, or that ii) receives a data packet transmitted by a mode different from the source node S to retransmit the data packet generated by the source node S, and is a multipoint relay of this

3914450

Date Reçue/Date Received 2020-04-28 different node, and referring to this other node as the receiving node, this receiving node performs the following operations, in order to determine whether or not to retransmit the data packet received. Before describing these operations, hereinafter reference is made to multicast packet to indicate, indifferently, the data packet transmitted by the source node S and addressed to the group 4, or a data packet equal, with regard to the data content, to the data packet transmitted from the source node S, but transmitted by a different node from the source node S, in order to retransmit the data packet generated by the source node S. Furthermore, generic reference is made to the sending node to indicate the node that has transmitted or retransmitted the multicast packet to the receiving node; the sending node is a neighbour of the receiving node. Hereinafter, except where specified otherwise, it is also intended that the receiving node is a multipoint relay of the sending node.

That having been said, according to a first embodiment shown in Figure 2, and as previously mentioned, the receiving node is configured, in a manner which is in itself known, to select (block 7a) its multipoint repeaters and to determine (block 7b) its MPR selectors, as well as to determine (block 8), in a manner that is in itself known, its own routing table. In addition, the receiving node is configured to determine (block 9) its group table, i.e. to determine, for each group, the corresponding group address and the addresses of the member nodes.

Following the reception (block 10) of the multicast packet, transmitted or retransmitted from the sending node, the receiving node checks (block 11) if it is a multipoint relay of the sending node, i.e. if the sending node is an MPR selector of the receiving node; in addition, although not shown, the receiving node checks that the packet received is

3914450

Date Reçue/Date Received 2020-04-28 effectively a data packet potentially to be retransmitted, and is not, for example, a HELLO packet.

In the case where the receiving node is not a multipoint relay of the sending node (NO exit from block 11), it does not retransmit the multicast packet.

Otherwise, if the receiving node is a multipoint relay of the sending node (YES exit from block 11), the receiving node detects (block 12) the group address contained in the multicast packet and performs the operations described hereinafter. In this example, the receiving node detects the group address that identifies the group 4.

In detail, the receiving node selects (block 14) each of the (node) addresses contained in the entry of its group table with a group address equal to the detected group address, the latter being equal, in this example, to the group address that identifies the group 4. Hereinafter, these addresses, contained in the group table, are referred to as the addresses of the nodes of the group. It should also be noted that in Figure 2, as also in the following figures, the operations are shown, for simplicity of representation, in sequence, although some operations or parts of them may be carried out in in an order at least partially different from that shown; in other words, the flowcharts shown in Figure 2 and in the successive figures are purely qualitative.

As shown in Figure 3, given a first address selected from the addresses of the nodes of the group, the receiving node selects (block 20) the entry in its routing table with a destination address equal to this selected first address, and then checks (block 22) if the next-hop address of the selected entry is equal to the address of the sending node, in which case the receiving node selects a successive address from the

3914450

Date Reçue/Date Received 2020-04-28 aforementioned addresses of the nodes of the group and repeats the operations in blocks 20 and 22.

In practice, given an address selected from the addresses of the nodes of the group and indicating the node whose address is stored as the next-hop address in the entry in the routing table with the destination address equal to the given selected address as the corresponding next hop, the receiving node checks (block 30, Figure 4) a first block condition, i.e. it checks if all the next hops corresponding to the addresses of the nodes of the group are equal to the address of the sending node. If this is true (YES exit from block 30), the receiving node does not retransmit the multicast packet, otherwise (NO exit from block 30) the receiving node retransmits the multicast packet, so that it still contains the group address of the group 4.

With specific reference to the example shown in Figure 1, if the receiving node is one of the first and second relay nodes RI and R2, it retransmits the multicast packet, in the same way as happens in the SMF protocol. Instead, if the receiving node is one of the first and second block nodes Bl and B2, it does not retransmit the multicast packet. In fact, if the receiving node is alternatively equal to the first or the second block node Bl or B2, it has a routing table such that the next-hop address of all the entries related to destinations that belong to the group 4 is equal, respectively, to the address of the first, or the second relay node RI or R2; in both cases, the next-hop address thus corresponds to the node from which the receiving node has received the multicast packet. In this way, the pointless retransmission of multicast packet to areas of the mobile telecommunications network 1 not forming part of the group 4 is prevented.

According to a different embodiment, described hereinafter and still making reference, purely by way of example, to the source

3914450

Date Reçue/Date Received 2020-04-28 node S, the information contained in its routing table can be used in order to further optimize the multicast flow.

As shown in Figure 5, the source node S generates (block 40) the multicast packet and then transmits the multicast packet, so that it contains a time-to-live (TTL) field, in which a TTL counter is present. In particular, the source node S initially sets the TTL counter equal to an initial value TTL_IN, of integer type for example.

When the receiving node receives the multicast packet, if the first block condition is not respected (NO exit from block 30), the receiving node checks (block 42) if a second block condition is respected, this being that the TTL counter contained in the received multicast packet is less than one, i.e. zero. If the TTL counter contained in the received multicast packet is less than one (YES exit from block 42), the receiving node does not retransmit the multicast packet; otherwise (NO exit from block 42), the receiving node, which is a multipoint relay of the sending node, retransmits (block 44) the multicast packet, after having decremented the TTL counter by one unit. It should be noted that, for simplicity of representation, in Figure 5 the operations performed before block 30 are no longer shown, apart from the aforementioned operations in block 40.

It follows that, if at least one of the first and second block conditions is respected, the receiving node does not retransmit the multicast packet, i.e. it blocks retransmission. Furthermore, on each successive retransmission of the multicast packet, the value of the TTL counter drops by one unit. When the aforementioned receiving node receives a multicast packet containing a TTL counter equal to zero, it does not retransmit the multicast packet, independently of respecting the first block condition.

3914450

Date Reçue/Date Received 2020-04-28

From a different viewpoint, and with reference, for simplicity, to the mobile telecommunications network 1 shown in Figure 1, the receiving node checks if a retransmission condition is respected, this comprising:

i) the fact that at least one address exists among the addresses of the nodes of the group 4 (stored in the group table of the receiving node) whereby the entry of the routing table of the receiving node that includes a destination node address equal to this at least one address contains a nexthop node address that belongs to a different node from the sending node; and ii) the fact that the TTL counter contained in the multicast packet transmitted by the sending node is greater or equal to a limit value, the latter being, for example, equal to one.

Furthermore, the receiving node retransmits the multicast packet only if the aforementioned retransmission condition holds.

In still greater detail, the source node S chooses the initial value TTL_IN so as to enable reception of the multicast packet by the group node 2 furthest from the source node S. To this end, given a maximum possible distance dmax between any group node 2 and the source node S, this distance being intended as a number of hops, the source node S sets the initial value TTL_IN such that the relation TTL_IN^dmax is true. For example, the relation TTL_IN=dmax+l may be applied, in order to ensure a safety margin and enable reaching even a possible group node that has moved away during the diffusion of the multicast packet due to high mobility.

With reference to the example shown in Figure 1, each group node 2 is more than two hops away from the source node S, and so the relation TTL IN^2 holds.

3914450

Date Reçue/Date Received 2020-04-28

The advantages that can be achieved with this communication method clearly emerge from the foregoing description. In particular, this communication method implements a routing protocol of the mesh based type. Therefore, this communication method enables limiting the diffusion of a multicast flow in areas of the network where there are not any nodes belonging to the group, without resorting to a tree distribution, which in itself is susceptible to topological changes in the network. Conversely, this communication method contemplates making use of local metrics, exploiting information already present within the nodes, in order to enable the multipoint relays to decide whether or not to relay multicast traffic.

In practice, for the retransmission of the data packets, this communication method contemplates using subsystems of multipoint relays and, in particular, multipoint relays positioned around unicast paths placed between the source node and possible destination nodes.

Finally, it is clear that modifications and variants can be made to this communication method, without departing from the scope of the present invention, as defined in the appended claims.

For example, the information contained in the tables and in the entries mentioned in the description, as well as inside the control packets, may be organized differently with respect to that described; in addition, part of this information may be absent. The actual formats in which the addresses are stored may vary from node to node and/or table to table, without this implying any breakdown in the correspondence between each node and the address that identifies it.

Furthermore, in general and as previously mentioned, the described operations may be carried out in a different order

3914450

Date Reçue/Date Received 2020-04-28 with respect to that described; purely by way of example, it is possible that the checks in blocks 42 and 30 are performed in reverse order with respect to that shown in Figure 5, and therefore that the check in block 30 and the associated operations are only performed if the TTL counter contained in the received multicast packet is greater or equal to one. Furthermore, some of the operations shown in a sequence may be performed substantially at the same time. In addition, some operations are repeated over time.

As previously mentioned, there may also be numerous groups in the mobile telecommunications network 1.

Furthermore, within each group, the transmission of the data packets takes place according to the standard SMF protocol, and so, as previously mentioned, known types of techniques may be adopted for detecting duplicated data packets, in order to avoid pointless retransmissions and the formation of loops.

It is also possible that the communication method is implemented, for example, entirely at the MAC layer, without resorting to upper layers.

It is similarly possible that the multicast packet is not a data packet, but a control packet, for example.

In addition, although this can cause an increase in traffic, it is possible that, given any node, all of its neighbouring nodes are multipoint relays of this node, in which case the receiving node does not perform the checks in block 11.

Finally, this communication method can also be adopted in the case where the nodes are fixed and the network is therefore not of the mobile type.