GB2554370A - Method for operating a reception device in a system using multi-copy transmission - Google Patents

Abstract

Operating a receiver of multiple copies of ordered packets by several routes of a communication network (i.e. a multi-path arrangement) 650. The copies of a same packet have a same index (sequence ID) in the order of the packets. The method comprises: determining, for each route, the index of the last received copy of a packet; upon reception of a copy of a packet from one of the routes: assessing, based on the determined indexes for each route, a frontier index 655 for which a reception of a copy having that index or a lower index is no longer expected from any of the routes, updating the frontier 655, and allowing release 660 of received copies of that packet. The method controls when packets are released, e.g. to be processed/decoded, whilst minimising latency and storage requirements. The received copy of a packet may be checked for errors and allowed to be released if it is error-free (670, Fig. 6c) or if an error-free packet can be recovered from the already received copies (675, 680, Fig. 6c). The frontier index may define the boundary of a storage part and a reading and decoding part of a shared memory.

Description

(71) Applicant(s):

Canon Kabushiki Kaisha (Incorporated in Japan)

30-2, Shimomaruko 3-chome, Ohta-ku, 146-8501 Tokyo, Japan (56) Documents Cited:

GB 2509435 A US 20040100963 A1

US 20120106330 A1 US 20020075873 A1 (72) Inventor(s):

Lionel Tocze Brice Le Houerou (58) Field of Search:

INT CL H03M, H04L, H04W

Other: WPI, EPODOC, TXTA, XPESP, XPI3E, XPIEE, XPIETF, XP3GPP (74) Agent and/or Address for Service:

Santarelli

49, avenue des Champs-Elysees, Paris 75008,

France (including Overseas Departments and Territori es) (54) Title of the Invention: Method for operating a reception device in a system using multi-copy transmission Abstract Title: Method for operating a reception device in a system using multi-copy transmission (57) Operating a receiver of multiple copies of ordered packets by several routes of a communication network (i.e. a multi-path arrangement) 650. The copies of a same packet have a same index (sequence ID) in the order of the packets. The method comprises: determining, for each route, the index of the last received copy of a packet; upon reception of a copy of a packet from one of the routes: assessing, based on the determined indexes for each route, a frontier index 655 for which a reception of a copy having that index or a lower index is no longer expected from any of the routes, updating the frontier 655, and allowing release 660 of received copies of that packet. The method controls when packets are released, e.g. to be processed/decoded, whilst minimising latency and storage requirements. The received copy of a packet may be checked for errors and allowed to be released if it is error-free (670, Fig. 6c) or if an error-free packet can be recovered from the already received copies (675, 680, Fig. 6c). The frontier index may define the boundary of a storage part and a reading and decoding part of a shared memory.

Figure 6b

1/12

102

ΙΌ

CM

Figure 1

2/12

201 202 203 ο

CM

CM CM

Figure 2

3/12

Route Id = 40 o

CM

LO

O

4/12

Figure 4

5/12

6/12

ο co ω

Ο)

CO

CO

Φ

3)

7/12

Timeout Calculate route (or new active route)?

ω
Φ	qj 4-» Z5
O s_	O
Γ)
,> M—	Φ
'43 “O	>
C —.	4-»
-D ω	o to
(Z)

rJ		/ °
	in \ i	/ ’ fi-
o	co V
co	fi- T
fi-

Φ		Φ
>	n-· \	>
4-J o	Φ \ 4-» \
to	Z5 /
Φ	O /
c o	L_ /

CuO	OJ
c	u
	c
4—·	OJ
to	Z5
4—' (/)	CT
	QJ	LU
o	(/)	(Z)
4—	c	_I
qj	o	<
O	4—'	LL
c	Q.	II
to	OJ
4—' (/) Ό	O OJ	2 -c U
4—'	4—'	C
Z5 to	o
4—	to
QJ	□_
Ό
4—'	ί
OJ	OJ
(Z)	c

ω

O) in fi-

8/12

Packet_Receive descriptor

9/12

Manage NWK Packetld Fi^UTG 9

10/12

Figure 10

11/12

Receive new value NWK Packetld ?

12/12 co

CM

Φ o

o

CM

X\Z

o

Μ^-

Φ

O

O'

IO

CM

Φ

O

O'

Φ

O

O'

TO >

Φ

CM

Φ

3) o

M

CM /χΛ u

Π!

a.

IL .

at

CM

IO

CM to

CM

IO

CM

CO

CM

IO

CM o

co

IO

CM

CO

IO

CM o

co

IO

CM

CO

IO

CM m

mCM

CO

CO

IO

CM

CM

CO

IO

CM

All packet from index (35 -RD^ -1) are received

FIELD OF THE INVENTION

The invention relates to the technical field of multi-copy processing.

More particularly, the invention relates to a method for operating a reception device receiving multiple copies of ordered data packets by several routes of a communication network.

BACKGROUND OF THE INVENTION

The invention deals with a method to handle multiple-copy management, for example in the context of a high data rate wireless communication link composed of multiple transmissions of same data through different paths or routes. Links for data rate wireless communication are established to support mobility and environment versatility.

For example, multiple transmissions of same data through different routes may be used in a video communication system to support high data rate video communication link(s) between a mobile wireless device and a fixed application belonging to an infrastructure network.

Although the invention is hereafter explained with reference to this particular application, it should be understood that it may be implemented for any system comprising a reception device receiving multiple copies of ordered data packets from several routes of a communication network (wired, wireless or comprising both wired and wireless routes).

In known example systems, a mobile wireless source device, such as a video camera or a Head Mounted Display (HMD), communicates over 60GHz unlicensed radio band using short distance Multi-gigabit data rate wireless 802.11 ad standard technology with several nodes (stations) in order to cover a limited movement area (such as a 15 m x 15 m square room). Multiple copy transmission on separate network paths (e.g. to several reception nodes) is used, in order to efficiently face possible loss of packet copies due to masking effect or shadowing on some paths of the 60 GHz wireless network.

The copies of a same data packet transmitted through different paths may be subject to different latencies due to the network transmission method or methods, such as TDMA (Time Division Multiple Access) for wireless, or CSMA/CD (Carrier Sensed Multiple Access with Collision Detection) for Ethernet, where data are transmitted in different periods of time.

These copies may also be subject to retransmission delay due to transmission errors, for example if ARQ (Automatic Repeat Request) is used.

The nodes of the infrastructure network of these example systems are then interconnected either through wired technology communication such as Ethernet, or through another wireless technology communication (such as 808.11 ac or 802.11 an), to a sink device of the video communication system. The infrastructure network may be considered to be non-sensitive to perturbation and able to sustain the data throughput to forward to the fixed application device (sink device).

The sink device may be a video storage (or display) in a system comprising a video source camera that provides high resolution image capturing facility. In a system comprising an HMD, the sink may be a Computer Graphic which adds virtual images to the video received from HMD taking into account the location and positioning of the HMD. This enhances the experience provided to the user of the HMD. The enhanced image is then provided by another communication link to be displayed on the HMD.

Patent application US20150026542, whose title is “method, device and system for packet transmission over IP networks”, describes a method for multiple copy transmission on separate network paths. This document describes a method for packet transmission over IP networks wherein redundant IP packet streams are generated by an IP transmitter and transmitted using separate network paths to one or more IP receivers. At each IP receiver, duplicate IP packets are overwritten to form a single combined packet stream. By using redundant IP packet streams the effects of packet loss and of network congestion can be reduced.

This method makes it possible to manage the reception of multiple correct (i.e. error free) packets by using a fixed latency time before the received packet is processed. However, this method is not optimized in terms of latency, and is not able to adapt to potential latency variation in the network. Moreover, this method requires a memory buffer adapted to store the packet received during twice of the fixed latency time.

Furthermore, it does not properly manage the case where no error-free copy of a packet is received.

There is provided in the invention a method that makes it possible to efficiently benefit from the multi-copy communication scheme while introducing a minimal latency.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, there is provided a method for operating a reception device receiving multiple copies of ordered data packets by several routes of a communication network, the copies of a same data packet having a same index in the order of the data packets, the method comprising:

- determining, for each route, the index in the order of the data packets of the last received copy of a packet;

- upon reception of a copy of a data packet from one of the routes:

- assessing, based on the determined indexes for each route, a frontier index for which a reception of a copy having that index or a lower index is no longer expected from any of the routes

- allowing release of the received copies of a data packet for processing if the reception of another copy of this data packet is no longer expected.

The method provided estimates from any new data packet received by any route the packet for which all the copies that can be expected have been received. This method thus makes it possible to manage the correct data reception, when temporarily some routes or paths in the transmission are shadowed or subject to errors or variable network latency, or manage a correct access method when multiple-copies are received disordered.

Such a method optimizes the latency of the system, as the reception device does not wait for a copy of a data packet that will never or very belatedly be received before allowing said packet to be processed. The method is independent of the communication method and enables adaptation to network latency variation.

The method provides a solution able to handle high continuous IP data rate application with low latency.

In this method, the step of allowing release may further comprise:

- checking the presence of errors in the received copy of the data packet; and

- allowing release of the received copy for processing if it is free of errors.

In such a case, the step of allowing release may further comprise allowing release of the received copies of a data packet if an error free data packet can be recovered from the received copies of said data packet.

According to an embodiment, the method may comprise determining whether a route is active or inactive, a route being considered inactive if no data packet of the ordered data packets has been received by this route for a predefined amount of time, and active otherwise. For example, a route becomes active after a first data packet is received on that route.

The method may also comprise calculating the difference between the index of the last copy of a packet received by each active route and the lowest determined index for an active route. The calculating step may for example be performed each time a copy of a packet is first received.

The method may comprise the calculation of the frontier index by the formula: index of the last first received copy of a packet minus the difference calculated for this route, minus one.

The frontier index may determine a frontier between two parts of a shared memory, respectively a part comprising copies having an index lower than or equal to the frontier index where access is provided only to reading and decoding processes, and a part comprising copies having an index higher than the frontier where access is provided only to storing processes.

In such an embodiment, a copy of a packet of data from a given route may be not released for processing until its index is not equal to or less than the frontier index.

The received copy of a data packet may be stored in a memory if:

- said copy is not released for processing, or

- no error-free copy of said data packet has already been received and stored.

The method may further comprise processing the copies which are released for processing, in the order of the data packets, and, if it is determined that no other copy of the data packet is expected to be received and that the received copy contains errors, processing may comprise:

- accessing the memory to retrieve previously stored copies of the received data packet;

- performing multi-copy decoding of the data packet based on the received data copy to obtain a decoded data packet.

The memory may for example be freed from all copies of a data packet when said data packet has been released for processing.

The assessing step may for example be performed at predetermined regular time intervals from a given starting time, or upon occurrence of a predefined event such as an evaluation request, and/or the detection of the use of a new route.

According to a second aspect of the invention, there is provided a reception device for receiving multiple copies of ordered data packets by several routes of a communication network, the copies of a same data packet having a same index in the order of the data packets, the device comprising:

means for determining, for each route, the index in the order of the data packets of the last received copy of a packet;

means for assessing, based on the determined indexes for each route, a 20 frontier index for which a reception of a copy having that index or a lower index is no longer expected from any of the routes; and means for allowing release of received copies of a data packet for processing if the reception of another copy of this data packet is no longer expected.

The invention also relates to a computer program comprising the instructions for implementing a method for operating a reception device as previously described, when it is loaded and executed by a processor. The invention also relates to a non-transitory computer readable medium comprising such a computer program.

BRIEF DESCRIPTION OF THE DRAWINGS

Other particularities and advantages of the invention will also emerge 5 from the following description.

In the accompanying drawings, given by way of non-limiting examples: Figure 1 illustrates a system example, where a multi-copy decoding method according to an embodiment of the invention may be used;

Figure 2 schematically illustrates a configuration of a communication 10 device 200, such as the communication device 105, 110, 115, 120 or 125 of

Figure 1;

Figure 3 shows an example of a Logical Link Connection (LLC) involving multiple data communication routes;

Figure 4 describes main fields of the data packet 400 managed by LINK 15 layer to implement algorithms described hereafter;

Figure 5 describes an algorithm performed by the source node 105 of Figure 3 to transmit the multi-copy data LLC packets on the selected routes;

Figures 6a, 6b and 6c illustrate a method for operating a reception device according to an embodiment of the invention wherein three processes respectively represented in Figure 6a, 6b and 6c are implemented.

Figures 7a and 7b illustrate algorithm steps performed on the sink node of an example embodiment to update a “Route distance table;

Figure 8a describes main fields of the memory descriptors used for the data packet reception;

Figures 8b describes organisation of shared memory after multiple packet receptions;

Figure 9 is an example algorithm for handling a packet received by a given node of the system, in particular the storage of the different copies in the shared memory using the descriptors of Figure 8;

Figures 10 describes more in detail step 985 of the algorithm of Figure θ;

Figure 11 illustrates an extracting/decoding process that may be used in embodiments of the invention to extract or decode data from a shared memory;

Figure 12a describes operation performed at predefined times to determine the “route distance” between the different routes due to the multi-copy transmission;

Figure 12b describes operation performed to determine the packets for which all the copies should have been received through the different routes, taking into account the latency introduced by the network.

DETAILLED DESCRIPTION OF EMBODIEMENTS OF THE INVENTION

As previously said, embodiments of the invention may be applied in any system comprising a reception device receiving multiple copies of ordered data packets by several routes of a communication network.

Figure 1 illustrates a system comprising a reception device in which an embodiment of the invention may be used. This system corresponds to the example application system previously mentioned.

The system 100 is designed to enable point-to-point communication between a mobile node 105 (mobile device) and a node 120 in a fixed location.

This communication is handled by at least two communication networks, where a first network 101 is a 60 GHz wireless network (such as specified by 802.11 ad standard) and a second network 102 is either a wired network such as Ethernet, or another wireless network.

The first (60 GHz wireless) network 101 comprises a mobile node 105 which is a mobile unit. The mobile node 105 may move in a limited area, under the coverage of several other 60 GHz wireless reception (and possibly transmission) node devices 110, 115, 120 and 125. The mobile node 105 is adapted to enter into communication with any of the nodes 110, 115, 120 and 125. If 802.11 ad is used, a PCP (Personal basic set service Control Point) controls all point to point connections in the 60 GHz network. In the represented example, PCP behavior is handled by the mobile node.

The mobile node 105 provides services to establish directional Multigigabit communications in the system 100 (also called radio paths), enabling data transmission with the different devices of the system.

Figure 1 also shows the second network 102 involved in the point to point communication between the mobile node 105 and the device 120. The second network 102 comprises the node devices 110, 115, 125 and 120 connected through wired gigabit Ethernet connections 130, 135 and 140.

The second network 102 is considered more reliable than the 60 GHZ wireless network 101 and provides relay (or forward) means of data for the point to point communication. The second network 102 enables indirect dual communication paths between nodes 105 and 120 (from/to 105 to/from 110, 115 or 125, and then to/from 110, 115 or 125 from/to 120).

Such a wired connection should require at least 3 Network interface cards available on node 120. A switch (not shown in Figure 1) may be provided to make it possible to use a single network interface card and to enable full interconnection of nodes 110, 115, 120, 125 by Ethernet.

In embodiments, the wired Ethernet interface may be replaced by a wireless technology (such as 802.11ac or 802.11η), assuming that the provided throughput is sufficient.

The second network 102 constitutes a means to enhance the coverage of the area provided for mobile node 105 and enables establishment of spatial diversity communication by the use of wireless multi-path communications. This spatial diversity may be obtained by the use of several station nodes (110 and 115 for example) and use of forward capability, or by the use of several directional Multi-gigabit communications radio paths with a same node using different antenna configurations.

As 60 GHz network is subject to fading issues and is sensitive to obstacles that may obstruct the data communication, a multi-path point to point communication scheme, called Logical Link Connection (LLC) is established between mobile device 105 and device 120.

In the represented example, a connection is established between a mobile camera source (forming or comprised in the mobile node 105) and a storage device at node 120. This Logical Link Connection is a point to point communication established between the two LINK layers 204 (shown in Figure 2), respectively of node 105 and node 120, and enables transport of data between application layers.

In the case of a system comprising a Head Mounted Display HMD as mobile node 105 or part of the mobile node 105, two Logical Link connections may be established: a first one from mobile node 105 to node 120 for transmission of the video as captured to a Computer graphic server, and a second one from server node 120 to mobile node 105 for transmission of an enhanced video to the HMD.

In order to provide reliable communications, the data are duplicated in so called “copies” and transmitted several times (at least two) through DMG (Directional Multi Gigabit) radio paths communication, with different characteristics such as antenna configurations or wireless destination devices (or, correspondingly for reverse connection, wireless transmitter devices). The data copies will therefore face different transmission delays, due to the different transmission times or the use of a device as relay (from the first network to the second network (or the reverse)).

The applicant has found that it would be advisable in such a context to find a method to benefit in the most efficient way from the multiple copies received, while introducing no or as little as possible delay in addition to that due to transmission.

Figure 2 schematically illustrates a configuration of a communication device 200 which may be implemented at node 105, 110, 115, 120 or 125 of

Figure 1.

A communication device 200, as used in at least one embodiment of the present invention and illustrated in Figure 2, may comprise:

- a Random Access Memory (denoted RAM) 203. In some embodiments, the size of the Random Access Memory can be extended by an additional Random Access Memory connected to an expansion port (not shown in Figure 2);

- a Read-Only Memory (denoted ROM) 202;

- a micro-controller or Central Processing Unit (denoted CPU) 201;

- a wireless communication interface 208, enabling communications with the other wireless communication devices of the network; and

- a second communication interface 218, wired (Ethernet for example) or wireless, enabling communications on a second reliable network between at least part of the devices (in the represented example, communications are possible between nodes 110, 115 , 120 and 125. Node 105 only requires wireless communication interface 208).

The CPU 201, Random Access Memory 203, Read Only Memory 202 and communication interface(s) 208, 218 exchange data and control information via a communication bus 210.

The communication device 200 having the general configuration described and illustrated in Figure 2 can either be a sending device (source), a receiving device (sink) or both (relay).

After the communication device 200 has been powered on, the CPU 201 is adapted to execute instructions from RAM 203, pertaining to a computer program, once these instructions have been loaded from ROM 202 or from an external memory (not shown in Figure 2). In embodiments of the invention, a computer program of this kind causes the CPU 201 to perform some or all of the steps of the algorithms or actions described hereinafter in relation to Figure 5, Figures 6a-c, Figures 7a and 7b and Figures 9 to 11.

The CPU 201 controls the overall operation of the communication device 200. CPU 201 acts as a data analyzer unit, which analyses the useful data payload (also referred as MAC payload) of a packet received from another communication device, either received through 60 GHz wireless and processed by the wireless communication interface 208, or received through the communication interface 218 (Ethernet for example).

The represented 60 GHz wireless communication interface 208 further comprises:

a Physical layer module (denoted PHY) 207;

- a medium access controller (denoted MAC) 206;

- an antenna 230.

The Physical layer module 207 is responsible for processing a signal output by the medium access controller 206 before it is sent out by means of the antenna 230. For example, the processing can be done by, modulation, frequency transposition and power amplification processes. Conversely, the Physical layer module 207 is also responsible for processing a signal received by the smart antenna 230 before it is provided to medium access controller 206.

The Medium Access Controller 206 manages the accesses to the wireless medium. MAC 206 also acts as a synchronization control unit, which controls synchronization relatively to a beacon interval, scheduling the transmissions via the wireless network. It means that MAC 206 schedules the beginning and the end of an emission of data in the network by the antenna 230, as well as the beginning and the end of a reception of data from the network by the antenna 230. The antenna module 230 makes it possible to support directional Multi-Gigabit data transfer by having possibilities to select sector for transmitting and receiving signals.

The represented second communication interface 218 further comprises:

- a Physical layer module (denoted PHY) 217;

- a medium access controller (denoted MAC) 216;

- an interface connection 240 (Physical cable for wired type interface or antenna for wireless interface).

The Physical layer module 217 is responsible for processing a signal output by the medium access controller 216 before it is sent out conforming to the electrical specification and the access mode of the interface connection 240.

Conversely, the Physical layer module 217 is also responsible for processing a signal received by the interface connection 240 before it is provided to medium access controller 216.

The communication device 200 may acquire and reproduce an application over the interface 220 connected to an application. This application can be for example a compressed video stream, a file storage, a video camera output or a display input.

The video application module 205 is responsible for converting application data into packets able to be transmitted over a network. The module 205 packetizes the application data and transmits it to the link layer controller. Conversely, the module 205 is also responsible for converting the received packets from the LINK layer 204 into a data application over the interface 220. One preferred embodiment of data packets managed by module 205 is TCP/IP or UDP/IP video lossless compressed data with a data rate between 400 Mbps and 1 Gbps.

The LINK layer 204 is responsible for the link establishment between the source and sink devices in order to transmit and receive the packets between the video application module 205 and the communication interfaces 208 and/or 218. The link layer controller, in a source device, generates and transmits data packets as explained in regards to Figures 4 to 5. In a sink device implementing an embodiment of the invention, the link layer controller decodes and recovers data packets from the multi-copy as explained in regard to Figures 6a-c to 11. A relay device (such as node 110 for example) only operates some subsets of the algorithm of Figure 9.

Figure 3 shows an example of a Logical Link Connection (LLC) involving multiple data communication routes. Figure 3 illustrates the concept of “route” in the context of the invention. Each route is composed of at least one wireless radio path in the 60 GHz network and optionally one or more additional paths in the infrastructure network which are either wireless (radio) or wired paths.

In the represented example, each device having a 60 GHz wireless interface has a MAC address denoted @rx, with x=1 for node 105, 2 for node 110, 3 for a node 115,4 for node 120 and 5 for node 125.

Another address denoted @ex, with same x value as specified for @rx, is identifying a second network interface (supposed to be Ethernet in this example embodiment).

Moreover, each node has an IP address denoted IPx (with same x value as specified for @rx), used by the application to identify a data packet communication and that will be the basis for the LINK layer to duplicate packets (i.e. to send copies) on selected routes.

A wireless path in the 60 GHz network may thus be identified by a tuple t_w = {@Tx, @Rx, (α,β)}, where :

- @Tx is the MAC address of the transmitter

- @Rx is the MAC address of the receiver

- (α,β) is an antenna configuration identifying the transmission angle a of @Tx and the reception angle β of the @Rx for the point to point communication.

A wired path, where no antenna configuration has to be defined, is only identified by a tuple t_e = {@Tx, @Rx}.

A route may thus be defined as:

- A source node IP address IP7x.

- A sink node IP address IPRx

- A set of tuples (t_e or/and tw) identifying the paths successively used for the transmission of data (from the source node to the sink node).

The routes are discovered by LLC through a message protocol and are shared and known by all the nodes of the system 100. This information is later referred to as “Route_Table” information. During a Logical link establishment phase, the numbers of routes to be used for communication is set (for example 3 routes for transmission of 3 copies) and the best available routes are selected from among the available discovered routes. These routes are known by their “Route_ld” value inside the “Route_Table (e.g. “Route 11” corresponds to the route having 11 as Route_ld value in the Route_Table).

More particularly, Figure 3 describes an example Logical Link Connection from the source node 105 identified by its IP address IP1 to the sink node 120 identified by its IP address IP4. The Logical Link Connection of the represented example uses three routes:

- Route 11 (300) which is a direct wireless communication link defined by(IP1,IP4,[{@r1,@r4,(ai,Pi)}])

- Route 40 which is a link composed of a wireless path 305 from node 105 to node 110, and of a wired path 310 from node 110 to node 120, defined by (IP1,IP4,[{@r1,@r2,(a₃,p₂)},{@e2,@e4}]).

- Route 25 which is a link composed of a wireless path 315 from node 105 to node 115, and of a wired path 320 from node 115 to node 120, defined by (IP1,IP4,[{@r1,@r3,(a₆,p₂)},{@e3,@e4}]).

The Route 66 also represented in Figure 3 and defined by (IP1,IP4,[{@r1 ,@r5,(a₄,p₄)},{@e5,@e4}]) (i.e a wireless path 325 and a wired path 330), represents another route discovered between the source node 105 and the sink node 120, but not selected (as represented by the dotted lines) for the current Logical Link. This route is kept and could be later selected by another LLC protocol, for example to replace one of the current selected routes.

Other routes using different antenna configurations could also exist between nodes of the 60 GHz wireless network (for example Route 1 defined by (IP1,IP4,[{@r1 ,@r4,(a₄,p₂)}])), providing path diversity (not shown in Figure 3).

Figure 4 describes the main fields of a data packet 400 managed by the LINK layer to implement algorithms described hereafter and implemented in embodiments of the invention.

In particular, the LLC packet may be composed of three main parts.

A first part, called LLC header 410, contains information generated or checked by the LINK layer, and makes it possible to analyse and determine operations to perform with the packet, such as forwarding, dropping or storing as explained in the algorithm represented in Figure 9.

The LLC Header 410 may contain at least the following information:

- a “Type subfield 411 identifying if the packet is a proprietary packet,

i.e. an LLC data type packet to be processed implementing a multi-copy transmission process;

- a “Route_ld” subfield 412 identifying in the “Route Table” the paths on which the copy of the application data is to be transmitted;

- a “Seq_ld subfield 413 identifying the transmission of the same data application packet 420 among all the copies of packets transmitted through the routes. This subfield corresponds to an index in the ordered sequence of the packets to be transmitted, and is used to ensure the right delivery order at the destination node. After each multi-copy data application packet transmission (as explained in Figure 5), this subfield is increased.

- a Header CRC, or HCRC 414, which is an error detection code added to protect the information of the LLC header. If an error has occurred during transmission, the information of the LLC header is corrupted and is no longer reliable. Thanks to this information, a corrupted LLC packet may be identified and, for example, dropped.

A second part, IP application data Packet 420, corresponds to the data as provided by the source application using the service of the LINK layer to transmit said data to the sink application using multi-copy. In a preferred embodiment, the IP application data Packet 420 is an UDP/IP packet (or a packet related to a service using IP as protocol layer) and identifies the IP address IPx of the destination node to which the packet is to be transmitted. The identification of the IP address (IPdest), knowing the IP address of the source node (IP_src) (i.e. IP of the node transmitting), enables the multi-copy transmission on each route selected in the “Route_Table”, with IP7x= IP_src dnd IPRx = IPdestA third part, called LLC footer 430, contains information to detect transmission errors that could occur on some sub-part of the IP application data packet 420. For example, up to n (n=8 for example) Cyclic Redundancy Check (CRC) code are calculated (431, 432 and 433). The calculation of each CRC is performed on a different fixed sized (of M Bytes) subdivision of the IP application data packet 420. The calculated CRCs are then aggregated in the LLC footer 430, where CRC1 431 enables error detection of the M first Bytes of the IP application data packet 420. Similarly, CRCi (432) makes it possible to detect errors and correct the [(i-1)*M, i*M] Bytes of the IP application data packet 420.

With such an LLC footer, an application packet of (n*M) Bytes may be protected and may therefore be handled by algorithm. When a packet is less than n*M bytes long, some CRC subfields may not be calculated (for example, CRC_n and CRCn-ι are not calculated if the payload is (n-2)*M Bytes long). Nevertheless, in the represented embodiment, the LLC footer is always composed of n CRC items of information.

The IP application data packet 420 and the footer 430 are the same in each copy of a same packet, while said packet is identified by the “Seq_ld” subfield of the LLC Header 410.

As an LLC packet is transmitted through the medium access controller (MAC) 206, in a way identified in the tuple t_w or t_e of the “Route_Table” information, the medium access controller adds to each LLC packet additional information containing at least the source MAC and the destination MAC (either @rx or @ex). This information is provided at reception of the LLC packet to the LINK layer to make it possible to identify the path used among the route information.

Figure 5 describes an algorithm performed by the source node 105 of the example embodiment of Figure 3 to transmit the multi-copy data LLC packets on the selected routes (i.e. the routes having a “Route_ld” equal to 11, 25 and 40 in the represented example).

In a first step 500, the LINK layer 204 of node 105 receives an IP application data packet 420 from the video application module 205. The IP address of the destination node IP_dest is checked and if it corresponds to the address of a selected route sink IPRx, the algorithm process further for multi-copy transmission of the packet.

For example, in the embodiment of Figure 3, if in the IP application data packet IP_dest equals IP4, step 510 is then performed. Otherwise, the packet is transmitted by using a conventional IP transmission (using a single copy) and is not handled by the LINK layer. By this way, multi-copy transmission is performed only for adapted predefined applications.

At step 510 the number of routes “Nb_Routes” is determined. It corresponds to the number of copies of the IP application data packet 420 that must be transmitted. It is determined by counting the number of selected routes in the “Route_Table”, where IP7x= IP_src and IPRx = IP_dest- In the described example, “Nb_Routes” is 3.

Then, at step 520 an initial value of the transmitted copies “NbCopyTx” is set to zero.

At step 530, the LLC footer is added to the IP application data packet, as described with regard to Figure 4. It should be noted that this step is only performed once for each LLC packet to be transmitted, as the IP application data packet and LLC footer are the same in each copy of a LLC data packet to be transmitted.

The value of counters “NbCopyTx is then checked at step 540 to verify if all the copies of the data packet have been sent.

If the number of copies transmitted is less than the number of selected routes (i.e. all the requested copies have not been sent yet), the source node 105 has to generate a new copy of the data packet.

For generating a new copy, the “Route_ld” of the “NbCopyTx’^,Vn element of the “NbCopyTx selected “Route_Table whose IP pair matches (IP_src, IPdest) is retrieved at step 550.

Then, at step 560 the LLC header as described in Figure 4 is created and added for the current copy. For creating this header, the subfield “Route_ld” 412 is added using the value retrieved at step 550, the subfield “Seq_ld” 413 is added according to the current value of an internal counter incremented for each LLC packet to be transmitted (see step 580 hereafter described). The correct HCRC is calculated and added.

Then, the LLC data packet is provided for transmission (at step 570) to the medium access controller that corresponds to the address @Tx of the first path of the “Route_Table element describing the selected “Route_ld”. For example, if “Route_id” = 11 (or 25, or 40), @Tx is equal to @r1, meaning that transmission is performed by wireless interface of node 105.

If the transmission is in the opposite direction (from node 120 to node 105), an @Tx = @r4 corresponds to the use of the wireless interface of node 120, and an @Tx = @e4 corresponds to the use of the wired interface of node 120 and therefore to the use of a relay (which may be node 110, 115 or 125) to reach through wireless communication the destination node 105.

When a request of transmission is done, then the value of “NbCopyTx” is incremented.

The medium access controller then proceeds to the requested transmission on the corresponding medium. Additional information are added to the LLC packet, such as the MAC source and destination addresses. These addresses correspond to the first tuple of the the “Route_Table element describing the selected “Route_ld”. For example, for “Route_ld” = 11, the MAC adds (@r1, @r4) as MAC source and destination addresses and for “Route_ld” = 40, the MAC adds (@r1, @r2) as MAC source and destination addresses.

Then, the algorithm returns to step 540, to check if the transmission of another copy has to be performed on another selected route.

If the number of copies transmitted equals the number of selected routes, multi-copy transmission of the IP application data packet is finished (step 580). In this step the internal counter used for “Seq_ld” is incremented.

Therefore, the variable “Seq_ld is an index that makes it possible to determine the order of data packets transmitted in an ordered sequence of data packets. It also makes it possible to identify copies belonging to a same data packet.

Figures 6a, 6b and 6c show a high-level overview of a method for operating a reception device according to an embodiment of the invention. The flowcharts of Figures 6a, 6b and 6c may be executed in parallel.

Figure 6a concerns the calculation of (route) distances, counted by 5 packet, between different routes and keeping those distances up to date. This removes the difficulty of implementing a timer for each copy of a packet to determine when the last copy is expected or using a fixed maximum time in order to deliver data to upper layer (like in methods known in the prior art). This advantageously makes it possible to achieve high data rate transfers.

At step 600, the available routes (i.e. the routes of the Logical Link

Connection described with reference to Figure 3) are determined. In particular, the available routes may be identified by their respective Route_ld. They may be determined in the form of a list of routes (for example according to the order of their respective “Route_ld”).

The available routes are then successively considered. At step 610, the route from which the packet with the lowest Seq_ld is received, also referred to as the « slowest route », is determined. The comparison of Seq_lds is performed among sequence ids (indexes) of last copies of data packets received at a given evaluation time (t_evai) from the different routes.

Then, at step 620, for each route among the available routes, a distance, counted by packet, with the slowest route is calculated.

The concept of “Route Distance as defined on a sink node receiving the multi-copy LLC data packet may be illustrated by the following table which may be used in the invention.

Route distance is introduced and used in embodiments of the invention to estimate the “delay” (expressed in packet number) introduced on each route by the communication layer. The determined route distances are used, as hereafter explained, to decide whether or not to release the received copies of a data packet for further processing.

The table comprises a first index, which corresponds to “Routejndex. The value of the “Routejndex corresponds to the value of the subfield “Routejd’ of any LLC data packet received. The other information or values mentioned in a line of the table refers to the route identified by the “Route index” of this line.

The “Active information of the table indicates whether the route of “Routejndex is considered as active (e.g. the value is set to 1) or inactive (e.g. value set to 0). An inactive route corresponds to a route through which no more LLC data packets are received, and thus through which no more LLC data packets are expected. Whether a route is active or inactive may be determined according to the “Seqjd’ information of the table as hereafter explained. A route is considered active as soon as one LLC data packet is successfully received on the sink node. It is considered inactive when the distance between said route (which is the slowest) and the fastest route is above an inactivity threshold value (in number of LLC data packets). When this distance is above the inactivity threshold, the slowest route is determined as being inactive. In other words, a route is considered inactive when the Seqjd’ from that route does not change while the “Seqjd’ from at least another route continue to rise. Initially (before any transmission occurs), all routes are considered inactive.

The “Seq_ld” information of the table is an index in the ordered sequence of data packets to be transmitted which corresponds to the last LLC Header subfield “Seq_ld” successfully received (for the “Route_lndex” retrieved from subfield “Route_ld’). For example, when temporary masking occurs on a given route (identified by its “Route index”), “Seq_ld’ evolves by non-uniform steps due to the intermittent masking effect. When the route is blocked or is no longer selected for multi-copy transmission, “Seq_ld’ does not change anymore.

The distance information (i.e. the so called “route distance”) is the gap, calculated as a difference of “Seq_ld’ values between the slowest route on which a LLC data packet has been received, and the route having the considered “Route_lndex”. The slowest route is defined as the active route which has the lowest “Seq_ld’ value. Conversely, the fastest route is the route for which the “Seq_ld’ has the highest value.

Figures 7a and 7b provides a detailed implementation variant of highlevel overview of flowchart of Figure 6a.

Figure 6b concerns the determination, based on the calculated distances, of the limit (or frontier index) beyond which it is no more useful to wait for (further) copies of a data packet, and thus delivery of received copies for processing is triggered. In other words, the frontier is the limit below which packet copies are no more expected, and above or equal to which packet copies are still expected to be received. The delivery of data packet copies may consist into reading the copies in the memory from which processing is authorized.

At step 650, a copy of a data packet (belonging to the ordered sequence of packets to be received) is received by the reception device that implements the described method from one of the available routes.

At step 655, the frontier information is updated. Step 655 is performed based on the indexes (“Seq_ld”) determined for each route of the Logical Link

Connection. For example, if the Seq_ld of a data packet copy received from the slowest route is N, then all copies having a Seq_ld equal or smaller than N - 1 shouldn’t be expected anymore from any route. More generally, if the Seq_ld of a data packet copy received from a route that is at distance D from the slowest route is N, then all copies having a Seq_ld equal or smaller than N - D - 1 shouldn’t be expected anymore from any route. In either case, already received data packet copies having a Seq_ld that is lower or equal to N - D - 1 are ready for processing (e.g. the multi-copy decoding process). The term N - D - 1 represents thus the frontier updated based on the Seq_ld of the received data packet copies. Delivery of data packet copies for processing is performed at step 660 based on the frontier information as discussed above, i.e. received packet copies with a Seq_ld lower or equal that N - D - 1 are delivered for processing.

More details on the determination of the frontier, referred to as “NWK_Packetld is provided with reference to Figure 10.

Figure 6c concerns the processing of the delivered data packet copies. The processing may consist into reading from memory copies of data packets of which no further copies are expected to be received. Copies are obtained in the order of their sequence number. At step 665 delivered copies associated with a Seq_ld, i.e. one data packet, are obtained. At an optional step 670, a test is performed to determine if at least one copy is error-free. If the test if positive, the (error-free) copy is released for processing at step 685. If the test 670 is negative, a further optional test 675 is performed to determine if the data packet is recoverable from the available (received) copies. If the test 675 is positive, a multicopy decoding (optionally) is applied at step 680 (further described with reference to Figure 11) and one correct copy is released for processing at step 685. If test 675 is negative, the data packet is not recoverable and the flowchart loops back to step 665 for obtaining copies related to another data packet (Seq_ld).

Figures 7a and 7b illustrate algorithms (respectively a first algorithm and a second algorithm) which may be performed at the sink node to update the “Route distance table.

The update of information occurs in two occasions.

The first possible update scheme (according to the first algorithm illustrated in Figure 7a) may be performed each time a LLC data packet is received (and LLC Header CRC is correct). At step 700, the “Route_ld” subfield 412 of the LLC header is extracted and used as “Route_lndex” to update the information of the corresponding element in the “Route distance” table. At step 705 the “Active” information of the “route distance” table is set to 1, to indicate reception of a data packet from that route. A check is also performed to detect whether the route is a new route: a route is considered as a new route when the “Active” information is set for the first time.

At the last step 710, the “Seq_ld” value (retrieved from the received LLC header) is stored in the route table in the corresponding “Seq_ld” information of the “route distance” table, thereby identifying the last application data packet received for the route having the considered “Route_ld”. This information may be then used in the algorithm of Figure 7b which is hereafter described.

This first algorithm comprising steps 700 to 710 makes it possible to gather all information from all the routes, on which the multi-copy data are transmitted. It also makes it possible to perform an estimation of the delay, in terms of LLC packet “Seq_ld” difference, which reflects the latency introduced by each route used for the transmission through the different networks. This estimation may be performed as explained hereafter with reference to Figure 7b.

The second possible update scheme (according to the second algorithm illustrated in Figure 7b) may be performed at predefined times, for example at predefined regular intervals. This may be controlled by a regular timer (for example, set to trigger a timeout event every 5 seconds) at step 720. The periodic (e.g. regular) update of the route distance information provides up-to-date information as to the latency introduced by the network and/or makes it possible to detect inactive routes due to masking or obstacles.

The algorithm may also be performed each time a new route is used for transmission and detected. The copy available from this new route will thus be available (e.g. for further processing) as soon as possible. The test 720 indicates whether update of the “Distance information of all current active routes of the “Route distance table is to be performed.

At step 725, a test is performed to check for initial synchronisation of the system (test if a variable “Synchro is “TRUE”). The result of this test indicates whether the system is correctly set to manage the LLC data packet reception and storing (for example according to the algorithms of Figures 9 and 10) and the data application extraction/decoding (for example according to the algorithm of Figure

11). A correct setting may correspond to the fact that the variables used by the system for the management of data storing and extraction / decoding of a received LLC packet are correctly set (e.g. thanks to the reception and analysis of a first LLC data packet, as explained with reference to Figure 9). Such synchronization is necessary at the start of the system for the first start of transmission and after any cut of the transmission (detected when no more active route is present).

If test 725 is negative, then the update algorithm ends (step 755).

If the result of the test 725 is positive, the route having the lowest “Seq_ld’ is determined at step 730 among all the supposed to be active routes of the “Route Distance table (i.e. the routes for which the “Active element is set to 1) and constitutes a candidate slowest route. The corresponding “Route Index is then stored in an internal variable “Route lndex_Si_Owest_route”·

It should be noted that the counter “Seq_ld” may have in practice a limited range (it may be a 64 bits counter for example). At some time, loopback will occur and is managed by algorithm. For the sake of simplicity, the case where no loopback occurs is described.

At step 735, it is checked whether the candidate slowest route is still active. This is performed by checking the gap interval of this route with the fastest one, as previously explained with reference to the “Route Distance table. When this test is negative, it means that the determined candidate slowest route is in fact now inactive. The variable “Active is set to 0 for this route, and a further determination of the slowest route from among the remaining supposed to be active routes (if any) has to be performed. In that case, the algorithm process back to step 730.

If step 735 is positive, meaning either that the determined candidate slowest route determined is still active or that no active route exists, a test is performed at step 740 to check whether the result of step 735 was positive because the candidate slowest route is active or because no active route exists, by checking whether at least one active route exists.

If the result of the test at step 740 is positive, meaning that the candidate slowest route is active and is thus the slowest route, the route distance (“Distance” in the route distance table) is calculated for each active route at step 750 with the following formula :

Distance[Route Index] = Seq_ld[Route Index] - Seq_ld[Route lndeX_S|owest_route]

If check step 740 is negative, meaning that no route is still active, all “Distance values of the route distance table are set to an initial default value, to enable a further reception of a new multi-copy communication. In this case the variable “Synchro is set to FALSE, indicating that a synchronisation step is required before processing any step of the algorithms for LLC data packet reception.

After any of the steps 745 or 750, the algorithm ends at step 755.

Figure 8a and Figure 8b illustrate an LLC data packet memory storage and management organisation as handled and shared by the different reception process algorithms of the sink device in the represented embodiment of the invention. More particularly, Figure 8a describes the main fields of the memory descriptors used for the data packet reception, and Figures 8b illustrates a possible organisation of a shared memory after multiple packet receptions.

The storage management hereafter described has been developed to process a high data throughput with low delay, as it may be required for video IP data application (such as a head mounted display or a high resolution image capturing facility).

In video IP data application, a large and continuous amount of LLC data packets, moreover increased because of the use of multi-copy transmission, has to be received in the sink device. Therefore, sharing the used memory between a storing process (further described in Figures 9 and 10) and an extracting/decoding process (described in Figure 11) may be advantageous.

However, the sharing does not use a conventional memory access locking mechanism that may block the storing process, introducing possible packet loss due to congestion, or that may block the decoding process introducing additional delays.

In this context, Figure 8a describes the main fields of the memory descriptors used for the LLC data packet reception.

A first descriptor 800, called LLCJnfo descriptor, is formed based on information from the data packet LLC_Header, in order to gather all the copies received from a same data packet (having a same “Seq_ld”) and in order to organise the packets received in their order of extraction/decoding operation. The use of the LLC Info descriptor is later explained in the algorithms of Figures 9 to

11.

A second descriptor 810, called LLC_Payload descriptor, stores the received IP data application packet 420 as received in a copy (with or without errors) in the “IP data” field 811. For the copy stored in the “IP data” field 811, the “Error Mask’ field 812 stores a status issued from the comparison of the CRC calculated by the receiver to the CRC contained in the LLC footer 430 of the LLC data packet. If the two CRCs are equal, meaning that no error is present in the packet, the variable “Error Mask’ has a value of 0x00 (assuming the CRCs are calculated for detection of errors on 8 bits). Otherwise, any other value of “Error Mask’ indicates errors in the copy received, and also makes it possible to determine which subpart of the “IP data” is incorrect. For example, a value of 0x24 indicates that errors are present in the third subpart (CRC₃ comparison failure) and the fifth subpart (CRC₅ comparison failure) of the “IP data” of the LLC Payload descriptor.

One LLC Info descriptor may refer to one or more LLC Payload descriptors as illustrated by arrow 815.

A LLC Info descriptor comprises three fields:

- A “Seq_Rx_ld’ field 801 which stores the corresponding LLC header “Seq_ld’ subfield from the first copy received of the multi-copy LLC data packet. This information is later used to check whether a new LLC data packet (i.e. a first received copy of a packet) is received. The reception of a new packet is detected when no LLC_lnfo “Seq_Rx_ld” descriptor has a value equal to “Seq_ld” of LLC data packet). This information also makes it possible to locate where to store the new copy received;

- A “Nb_Recv” field 803 which indicates the number of LLC payload descriptors the LLC Info is referring to. This number indicates how many copies of an LLC data packet are available when a multi-copy decoding process is required, when none of the copies received is without errors.

- An “Is Correct” field 802, that is set to TRUE to indicate that the corresponding LLC Payload contains correct (i.e. error free) data and can be released to a local application. If not set to TRUE, it indicates that using the “Nb_Rec/ (at least 1) copies, a multi-copy decoding algorithm will have to try to correctly retrieve the original data.

Figure 8a also shows two reference links to the LLC Info descriptor.

Link 805 is a read link, which will be used by an extracting/decoding process as described with reference to Figure 11 to manage the packet delivery to the Sink application (e.g. to the video application module 205). The link 804 is a write link, which will be used by a storing process as described with reference to Figures 9 and 10 to manage the reception of a copy of an LLC data packet.

Figure 8b describes by way of example a possible organisation of shared memory after multiple packet receptions.

In the following example, three routes, namely Route 11, Route 25 and Route 40 are selected for multi-copy transmission, and the sink device has the following “Route Distance” table:

Route Index	Active	Seqjd	Distance
11	1	35	3
25	1	31	0
40	1	31	1
66	0

This route table corresponds to a state as determined for the last update timeout period. The slowest route is route 25 (distance of 0) and the fastest route is route 11 (its distance from the slowest route is the highest calculated distance, and is in the present example of three LLC data packets).

As shown, an LLC Info descriptor 820 may refer to a single LLC Payload descriptor 825 when “Error Mask’ indicates a 0x00 value. This corresponds to the case where at least one of the received copies of the LLC data packet has been received without error (the copy of packet No.29 received from route 11 in the represented example). The other copies (i.e. previously received copies comprising errors or copies received after reception from route 11 either comprising errors or error free) of this packet are dropped as an error-free copy of this data packet is stored in memory (as shown, the copies from route 40 and route 25 are not stored).

This is also the case for packet No. 35.

An LLC Info descriptor may refer to several LLC Payload descriptors. For example, the descriptors 830 and 840 refer respectively to 2 (835 and 845) and 3 (855, 865 and 875) LLC Payload descriptors.

In both cases, this corresponds to the reception from different routes (Routes 40 and 25 for 830, and routes 11, 40 and 25 for 840) of copies with errors as shown by the non-null “Error Mask’ values.

The descriptor 830 illustrates an example of a loss of packet from route 11 as no copy from this route is referred to (while the copies from the other routes contain errors).

Regarding descriptors 820, 830 and 840, all the copies that may be expected have been received and can be used for an extracting/decoding process, through the read link sequence starting from the initial link 821. As shown, the LLC Info descriptors are linked in their sequence order (29 to 31).

An LLC Info descriptor may also refer to an incomplete list of LLC Payload descriptors, i.e. to LLC Payload descriptors corresponding to an LLC data packet for which not all copies have been received yet, and the reception of copies may still be expected. This is the case for descriptors 850 and 860, which refer both only to one LLC Payload descriptor received from the fastest route, i.e. route 11 in the represented example.

However, regarding LLC info descriptor 850, the received copy contains errors as shown by the non-null value of “Error Mask’, or the corresponding fact that the Is Correct’ field is set to FALSE. Other copies of the LLC data packet (in addition to the copy of descriptor 855) are required to allow the release of the copies for processing (e.g. multi-copy decoding).

On the contrary, regarding LLC info descriptor 860, no other reception of a copy of the LLC data packet No. 35 is needed, because the LLC payload descriptor 895 to which it refers is free of errors, and may be released as such to an application (whether copies of the packet are well received through routes 25 and 40 or not).

It should also to be noted that the “Seqjd” (also corresponding to a packet number in the ordered sequence of packets to be received) of descriptors 850 and 860 shows that route 11 did not correctly provide the LLC data packet No. 33 and 34, as there is no LLC Info descriptor. It may be due to a retransmission (ACK mechanism of the MAC) or to a masking effect caused by an obstacle to the transmission.

Descriptors 850, 860 for which copies of LLC data packets may still be received could be used by a storing process through the write link sequence starting from an initial link 822. The storing process may be used either to add a new LLC data packet reference or to modify a list of links of the LLC Info descriptor 860 when a new LLC Info descriptor is inserted (in the represented example, if a copy with “Seq_ld” equal to 33 or 34 is received) or added after the current last LLC Info descriptor.

Thus, a concurrent access to the shared memory for the different processes (storing and extracting/decoding) is possible through the write/read link list without requiring any locking memory mechanism as soon as it can be ensured that a frontier is set for delimiting in which memory area data may be read and in which area data may be written, or, in the present case, which LLC Info descriptor is the last to be read or written.

This limit corresponds to the “NWK_Packetld” shown in Figure 8b.

As further described in Figure 10, this limit is calculated when any first copy of a (new) packet is received from any route. In the represented example, the last first copy of a packet is the copy of packet No.35 (first copy for which “Seq_ld= 35) received through route 11. The route distance of the corresponding route (as known from the route distance table) is subtracted from “Seq_ld”, and 1 is further subtracted. In the represented example and based on the above example route distance table, “NWK_Packetld” is equal to 35 - 3 - 1 = 31.

With such a limit, the read link is limited to LLC info descriptors 820 to 840, and the write link is possible from LLC info descriptors 860 to 850.

An exclusive memory access is therefore provided to the different processes concurrently.

Figure 9 is an example algorithm for handling a packet received by a given node of the system, in particular the storage of the different copies in the shared memory using the descriptors of Figure 8.

In an initial step 900, performed on starting the device, internal variables are set in order to ensure that all the context to manage the LLC data packet reception storing and data application extraction /decoding is correctly set. This step consists in particular in an initial setting of a default “Distance value in the distance field of the Route distance table and in the setting of the value of the “Synchro variable to FALSE. These settings ensure that the first packet received is correctly stored, even if the “NWK_Packetld frontier is not defined yet.

Then at step 905, the “NWK_Packetld” value is set to a default value of 0, corresponding to an undetermined initial state when “Synchro=TALSE.

At test step 910, it is estimated whether a data packet received is a proprietary type data packet corresponding to an LLC data packet. The variable “Type and the MAC Address source “@Tx are extracted from the header information. Based on the information of the variable Type, an identification of the LLC data packets is performed. If a received packet does not correspond to an LLC data packet, the algorithm waits for the next packet reception on any interface (as shown by the loop to step 910).

Otherwise (i.e. if the received packet is an LLC data packet), the LLC data packet is further analysed (at step 915).

At the test step 915, the LLC Header 410 of the received packet is checked to verify whether the header is correct or corrupted. This is performed by the computation, by the receiver, of the CRC using all subfields corresponding to the HCRC of the LLC Header, and by comparison of the result with the HCRC content. When values are not equal, this indicates that some information inside the header is corrupted and therefore should not be treated reliably. In this case, the LLC data packet is dropped (step 920). Otherwise treatment of LLC data packet continues in step 925.

At step 925, based on the MAC source address “@Tx” and the MAC address of the network interface from which the LLC data packet is received (“@/?x”), the algorithm determines whether the device receiving the packet is the final destination. This is done using LLC Header “Route_ld” subfield and the shared “Route_Table, by checking if the tuple in the “Route_Table” of index “Route_ld which contains the (@7x, @Rx) is the last tuple of the route.

If the receiving device is not the destination device, this device is a relay in the route. The corresponding node forwards the LLC data packet (step 930) through the next path defined by the next tuple information (either t_w or t_e), by adding the MAC source and destination addresses as explained in Figure 4.

If the receiving device is the destination or sink device the storing process continues at step 935.

At step 935, the “Seq_ld” subfield value from the LLC Header is retrieved.

A first check (at step 940) is performed based on the retrieved “Seq_lcT and the settings of the “NWK_Packetld” and the “Synchro variables. This step consist in checking the condition (“Seq_ld” > “NWK_Packetld) indicating that the packet is a packet that the storing process is authorised to write in the shared memory, or in checking the condition (Test “Sync/?ro”=FALSE) indicating the initial state (when the packet is the first received and “NWK_Packetld” is still not set) and in this case the LLC data packet is also to be stored.

If this is not the case (the result of the test of step 940 is negative), as it may happen for example for a delayed packet (e.g. due to retransmission of said packet) that arrives too late and is no longer authorised to be stored in the shared memory, the received LLC data packet is dropped (945).

Otherwise (if the result of the test of step 940 is positive), a new test is performed (at step 950), which determines:

- whether the LLC data packet corresponds to a new “Seq_ld”, meaning no corresponding LLC Info descriptor is found referenced by the write link list, starting from initial link 822 until the last LLC Info descriptor in the list having a “Seq_Rx_ld” strictly above “NWK_Packetld”,

- or whether the LLC data packet is a copy of a packet for which at least one copy has already been received, while the copy received contains errors (and therefore the additional copy should be kept for use in a further decoding process). This corresponds to a case where an LLC Info descriptor (that is in the memory area authorised for writing access) has “Seq_Rx_ld equals to “Seq_ld, with an “Is Correct’ field value set to FALSE (as for example the descriptor 850 in Figure 8b).

If none of these two cases is detected, corresponding to a received LLC packet which is a copy of a packet already stored with a correct LLC Payload, then the packet is dropped (at step 945). Thus, only useful copies are kept in memory, therefore optimising the memory space used by the algorithm.

If the test of step 950 is positive (the received packet corresponds to one of the two above cases), then a local CRC Footer is calculated at step 955 for the LLC data packet payload and an internal status Error Mask is determined by comparison with the received LLC Footer 430. The result of the comparison is 0x00 when CRC are equal, meaning that the LLC data packet received does not contain errors. As previously explained, the Error Mask formed by CRC comparison indicates the presence of errors in the IP application data, and also the block of the IP application data containing errors.

The verification of the CRC footer is then performed (at step 960), to determine how to handle the storage of the received packet. It is thus checked whether the status Error Mask is equal to 0x00.

If test 960 is positive (Error Mask is equal to 0x00), in step 965 an LLC Payload descriptor is created for the received LLC data packet, with the “Error Mask’ field set to 0x00 and the LLC IP data application payload received stored in the “IP data’’ field.

Then, if at step 950 it has been determined that the LLC data packet corresponds to a new “Seq_ld”, a new LLC Info descriptor is created (with the fields “Seq_Rx_ld” and “Nb_Recv” respectively set to the values of “Seq_ld” and to 1) and inserted in the sequence of LLC info descriptors at the right place according to the order of the “Seq_ld”. For example, according to the example of Figure 8b, at reception of an LLC data packet having a “Seq_ld” value of 34 from any route 40 or 25, a new LLC Info descriptor will be inserted between LLC Info elements 850 and 860, and the list of write/read links is updated. In this way, a reordering of the IP data application packet is performed.

If it has been determined at step 950 that the LLC Info descriptor already exists for the received copy, the corresponding previously received copies of the LLC Payload packet are dropped, as they contain erroneous payload and are no longer required as the received copy is free of errors. Then the LLC Info field “Nb_Recv” is set to 1. In both cases, the LLC Info descriptor refers to the LLC Payload descriptor created.

Finally, at step 970, the field “Is Correct” of the LLC Info descriptor is set to TRUE, indicating that the LLC Payload is directly usable for an extracting/decoding process. An LLC info descriptor set to TRUE also indicates as previously explained that the other received copies of the LLC packet may be dropped.

If test 960 is negative (the Error Mask is not equal to 0x00), at step 975 a LLC Payload descriptor is created for the received LLC data packet, with the “Error Mask’ field set to the determined non-null internal status Error Mask and the LLC IP data application payload received stored in the “IP data” field.

Then, if at step 950 it has been determined that the LLC data packet corresponds to a new “Seq_ld’, a new LLC Info descriptor is created (with fields “Seq_Rx_ld’ and “Is Correct’ respectively set to the value of “Seq_ld’ and FALSE) and inserted into the sequence of LLC info descriptors at the right place according to the order of the “Seq_ld”. In this case, the LLC Info descriptor refers to the LLC Payload descriptor created.

If it has been determined at step 950 that the LLC Info descriptor already exists for the received copy, an LLC Payload descriptor is added to the “Nb_RecV’ of the existing LLC Payload packets list, to participate (with the previously received and stored copies comprising errors) in the multi-copy decoding.

Then, in both cases, the LLC Info field “Nb_Recv” is updated (at step 980), corresponding either to setting the “Nb_Recv” field to 1 for a new “Seq_ld” LLC Info descriptor or to incrementing the “Nb_Recv” field value for an already existing LLC Info descriptor.

After step 970 or step 980, the algorithm executes step 985, which aims is to update the frontier “NWK_Packetld to manage the exclusive access to reading/writing memory areas.

Figure 10 describes step 985 of the storage process of Figure 9 in more detail.

In a first step 1000, a test is performed to check whether the LLC packet received corresponds to a new “Seq_ld’.

Indeed, an update of this frontier is only required at the first reception of an LLC data packet (i.e. when a first copy of a packet is received). This is done regardless of the route by which the first copy of the LLC data is received.

To determine whether a received packet corresponds to a first received copy of said packet, the result obtained at step 950 is used. If the received packet is not a first received copy, the algorithm is ended at step 1070. Otherwise, the algorithm executes step 1010.

At step 1010, an internal Result variable value is calculated by subtracting from the “Seq_ld” field received the value of the “Distance information contained in the Route distance table element corresponding to the “Route_ld” field index (i.e. the distance calculated for the route through which the packet has been received). As the distance is relative to the slowest route, the Result variable makes it possible to determine which one is the last packet (in the ordered sequence of packets to be received, or in other words, in the sequence of “Seq_ld”) for which a copy is still expected.

Therefore, all packet copies that can be received are already received for the packets having a number or index in the ordered sequence of packet to be transmitted (“Seq_ld”) below that value. For the packets having an index equal or inferior to the determined frontier, access to the memory where they are stored will only be provided for the reading process.

At step 1020, it is checked whether the current determination of the frontier is the initial determination of “NWK_Packetld” or not. This is done by reading the current value of internal “Synchro variable.

If “Synchro equals FALSE (the result of step 1020 is negative), which occurs on first initialisation of the connection, then step 1030 sets the initial value of “NWK_Packetld” to the value of the variable Result minus 1, and then in step 1040 “Synchro is set to TRUE (to indicate that the initialization is done).

If “Synchro equals TRUE (step 1020 positive), which occurs on a regular basis following the reception of packet copies through the different routes of the Logical Link connection, the algorithm performs the test of step 1050.

At step 1050, it is verified that the result of the subtraction operation (i.e. Result-1) is above the current NWK_packetld” frontier value. Indeed, due to the possible retransmission of packets, it may happen that new “Seq_ld” are not received in their original order and then the subtraction result may be lower than a previous calculation done for another new packet reception (of higher “Seq_ld”). However, the frontier is set to determine an exclusive access for different processes that may be executed in parallel and for complementary operations. In this context, the frontier (the value of “NWK_packetld”) cannot be decreased (excepted in case of loopback of “Seq_ld”, when “Seq_ld” is determined on a limited range as previously explained) as it could lead to inconsistent results of the algorithms.

If the result of the test performed at 1050 is negative, meaning that a packet of higher “Seq_ld” has already been received, the current value of “NWK_packetld’ is not changed and the update algorithm is ended (step 1070).

If the result of the test performed at 1050 is positive, the frontier is updated and “NWK_Packetld” is set to the value of (Result - 1) (step 1060).

Figures 11 is the algorithm performed at the sink device (120), after reception of the copies of the multi-copy of LLC data packets. This algorithm handles the delivery of IP application data to the Video application 205, and if necessary the decoding/recovery of these IP data from the different erroneous copies stored in the shared memory. This algorithm corresponds to a so called extracting/decoding process.

At an initial step 1100 the extracting/decoding process starts. This process may be executed in parallel with the storage process. A notification of availability of new data to deliver is notified each time a new “NWK_Packetk? frontier is determined.

Therefore, at step 1105, the algorithm tests whether a new “NWK_Packetld” notification has been received. As long as no notification is received (the result of the test is negative), the algorithm loops on the step 1105.

When a new notification is detected, step 1110 checks whether an LLC Info descriptor exits, by checking whether the read link sequence starting from initial link 821 is not referring to a null value. If this is not the case (the test performed at step 1110 indicates that the sequence refers to a null value), the algorithm returns to the notification waiting step 1105.

When the test indicates that the read link is not referring to a null value, a further test is performed at step 1115 to verify that the shared memory has an exclusive access for the extracting/decoding process. To this end, it is checked whether the field “Seq_Rx_ld” of the LLC Info descriptor which the link refers to is below the “NWK_PacketlcT frontier.

If this is not the case (the result of the test of step 1115 is negative), all the available IP application data has been released/delivered. The algorithm then returns to step 1105.

If the LLC Info descriptor is stored in the part of the shared memory that is reserved for the extracting/decoding process (the result of the test of step 1115 is positive), then the content of the “Is Correct’ field of the LLC Info descriptor is checked. If the field is set to TRUE (the result of step 1120 is positive), only one copy of the LLC Payload is stored for the corresponding packet t. As the packet copy contains no error the “IP data field 811 is provided as is by the LINK layer 204 to the application 205 (step 1140).

If the result of the test of step 1120 is negative, the algorithm will execute steps to check whether it can recover a correct “IP data from the stored copies containing erroneous data which have been received through the several routes of the Logical Link connection.

At step 1125, and based on the values of “Nb_Recv” and “Error Mask’ of the LLC Payload descriptors, the algorithm checks the complementarity of the different received data. A “Recoverable Mask’ value is computed. The computation may consist in a logical AND applied to all the “Error Mask’ values of the copies of the packet having the corresponding “Seq_Rx_ld’.

When the value of “Recoverable Mask’ equals 0 (the test of step 1130 is positive), then recovery (by multi-copy decoding) of a correct “IP data is performed at step 1135. It consists for example in starting from the first LLC Payload “IP data field to replace the erroneous sub-parts (as defined in Figure 4) of the IP application data packet, as identified by the corresponding bit set in the “Error Mask’, by the sub-parts of another copy for which the same bit in the “Error Mask’ is not set.

For example, for the LLC Info descriptor 840 of Figure 8b, considering the element 855 (from route 11), the value OxCO indicates that errors have occurred on the first and second subparts of the “IP data. Therefore using the second copy received (element 865 from route 40), only the first subpart is corrected (value 0x40) and the last copy (element 875 from route 25) is used to replace the second part as its value 0x10 is different from 0x40.

It should be noted, that the decoding process of step 1135 is always executed with the guarantee to successfully recover the “IP data, thanks to the initial test of step 1130. It may also be noted that more complex coding/decoding techniques than the one described for the LLC Footer creation and decoding may be used.

Once recovered, the packet is then released for delivery to the application layer 205 (step 1140), as when a single correct LLC Payload descriptor is available.

When the value of “Recoverable Mask’ is not zero (the result of the test of step 1130 is negative),it means that it is not possible to recover the correct “IP Data field of LLC Payload descriptors from the received copies of the data packet. In that case step 1145 is executed.

After step 1140, or when the result of the test of step 1130 is negative, the LLC Info descriptor for the “Seq_Rx_ld’ is removed from the LLC Info descriptor list. It means that the read link sequence starting from the initial link 821 is set at this stage to refer to the next LLC Info descriptor (for example by setting the initial link 821 to the link 805 of the removed LLC Info descriptor). At the same time, all LLC Payload descriptors (up to “Nb_Recv”) are then erased to free the shared memory. Then at step 1150, the same operation to read the next LLC Info descriptor is performed as at step 1110.

As long as the LLC Info descriptor list not empty (i.e. the initial link 821 is not null), then the algorithm repeats step 1115 to 1150. Thanks to this, all the elements in the shared memory for which exclusive access is granted for an extracting/decoding process are processed as soon as possible, in parallel with the storage process.

When the LLC Info descriptor list is empty (case test 1150 equals null), the algorithm returns to initial step 1105. This case occurs for example when the transmission of IP application data on the Logical link connection is completed.

Figures 12a and 12b illustrate respectively the calculation of the route distance (as explained in Figure 7b) and the determination of the “NWK_Packetld” frontier update process (as explained in Figure 10), according to the time of reception of packets of data through the different routes of the Logical Link connection.

In Figures 12a and 12b, information 412 and 413 gives the respective “Route_ld” and “Seq_ld” set of each copy of a data packet.

Missing packet receptions (e.g. due to obstacles) are illustrated on some routes. For Route 11, there is a missing packet having a “Seq_ld” value of 9; for Route 40 the packet No. 8 is missing (Figure 12a).

Figure 12a illustrates the operations performed at the evaluation time tevai, taking into account the last packets received on each route, to determine the route distance (as previously defined) between the different routes.

At the evaluation time, the “Seq_ld” of the last received packet on routes 11, 25 and 40 are respectively 12, 9 and 10. Therefore, as explained in Figure 7b a slowest route identification 1200 flag is associated with packet 1205 on route 25 and is used to calculate the route distance from each route of the Logical Link connection. The distance of each route (at the time t_evai) is determined as illustrated by values 1210, 1220 and 1230.

Figure 12b illustrates the operations performed on reception of a packet with a new “Seq_ld”. In the represented example, the packet No. 35 is first received on route 11. This determination is performed to determine frontier (in term of packet number or “Seq_ld”) for which all the copies should have been received through the different routes, taking into account the latency introduced by the network (as estimated in Figure 12a).

The packet 1245 is indicated by the flag 1240 as being a new first packet received. Then, applying the update algorithm of the “NWK_Packetld’ frontier described in Figure 10, it is determined that the packets having a “Seq_ld’ equal or inferior to (35 - Route Distance (R11) -1) are ready to be used for the multi-copy decoding process (of Figure 11). In the represented example, all the copies of the packets of “Seq_ld’ inferior to 32 are received from the other routes (routes 25 and 40).

The developed invention addresses the issue of deciding when to start multi-copy decoding without using timers to adapt to very high data rate transmissions.

In particular, an efficient concurrent shared memory access method between two parallel processes has been developed. This offers exclusive access to shared memory between a storage process and a retrieving/decoding process, without using a blocking mechanism (e.g. mutex or semaphore) or fixed timeout period, offering a low latency for the multi-copy transmission. Access to memory is granted exclusively for writing or reading to concurrent processes through the frontier index.

The method provided estimates from any new received data packet from any route the packet for which all the copies that can be expected have been received. This method thus makes it possible to achieve correct data reception, when some routes or paths in the transmission are temporarily shadowed or subject to errors.

Additionally, it permits also to manage missing packets in the ordered sequence. The multi-decoding process is not stalled by receiving no copy of a packet for a specific index.

Moreover, the method aims to provide an efficient memory storage, which reduces memory consumption by storing only relevant copy(ies) of the data packet(s) to enable correct delivery of application data, whether after decoding or not. This method also enables storage which complies with the initial packet ordering even if the copies of a packet are received disordered. Size of memory storage is also adapted to the network delay and is not overestimated, therefore providing efficient memory usage.

Claims (19)

1. A method for operating a reception device receiving multiple copies of ordered data packets by several routes of a communication network, the copies

5 of a same data packet having a same index in the order of the data packets, the method comprising:

- determining, for each route, the index in the order of the data packets of the last received copy of a packet;

- upon reception of a copy of a data packet from one of the routes:

10 - assessing, based on the determined indexes for each route, a frontier index for which a reception of a copy having that index or a lower index is no longer expected from any of the routes, and

- allowing release of the received copies of a data packet for processing if the reception of another copy of this data packet is no longer

15 expected.

2. A method according to claim 1, wherein the step of allowing release further comprises :

- checking the presence of errors in the received copy of the data

20 packet; and

- allowing release of the received copy for processing if it is free of errors.

3. A method for operating a reception device according to claim 2

25 wherein the step of allowing release further comprises allowing release of the received copies of a data packet if an error free data packet can be recovered from the received copies of said data packet.

4. The method of any one of claims 1 to 3, further comprising determining whether a route is active or inactive, a route being considered inactive if no data packet of the ordered data packets has been received by this route for a predefined amount of time, and active otherwise.

5. A method for operating a reception device according to claim 4, comprising calculating the difference between the index of the last copy of a packet received by each active route and the lowest determined index for an active route.

6. A method for operating a reception device according to claim 5, wherein the calculating step is performed each time a copy of a packet is first received.

7. A method for operating a reception device according to claim 5 or claim 6, comprising the calculation of the frontier index by the formula: index of the last first received copy of a packet minus the difference calculated for this route, minus one.

8. A method for operating a reception device according to any one of the preceding claims, wherein the frontier index determines a frontier between two parts of a shared memory, respectively a part comprising copies having an index lower than or equal to the frontier index where access is provided only to reading and decoding processes, and a part comprising copies having an index higher than the frontier where access is provided only to storing processes.

9. A method for operating a reception device according to any one of the preceding claims, wherein a copy of a packet of data from a given route is not released for processing until its index is not equal to or less than the frontier index.

10. A method for operating a reception device according to any one of the preceding claims, wherein the received copy of a data packet is stored in a memory if:

- said copy is not released for processing, or

- no error-free copy of said data packet has already been received and stored.

11. A method for operating a reception device according to claim 10 further comprising processing the copies which are released for processing, in the order of the data packets, wherein, if it is determined that no other copy of the data packet is expected to be received and that the received copy contains errors, processing comprises:

- accessing the memory to retrieve previously stored copies of the received data packet;

- performing multi-copy decoding of the data packet based on the received data copy to obtain a decoded data packet.

12. A method for operating a reception device according to claim 11, wherein the memory is freed from all copies of a data packet when said data packet has been released for processing.

13. A method for operating a reception device according to any one of the preceding claims, wherein the assessing step is performed at predetermined regular time intervals from a given starting time, or upon occurrence of a predefined event such as an evaluation request, and/or the detection of the use of a new route.

14. A computer program comprising the instructions for implementing a method according to any one of the preceding claims, when it is loaded and executed by a processor.

15. Non transitory computer readable medium comprising a computer program for implementing a method according to any one of claims 1 to 13.

16. A reception device for receiving multiple copies of ordered data packets by several routes of a communication network, the copies of a same data packet having a same index in the order of the data packets, the device comprising:

means for determining, for each route, the index in the order of the data packets of the last received copy of a packet;

means for assessing, based on the determined indexes for each route, a frontier index for which a reception of a copy having that index or a lower index is no longer expected from any of the routes; and means for allowing release of received copies of a data packet for processing if the reception of another copy of this data packet is no longer expected.

17. A method for operating a reception device implementing the processes as hereinbefore described with reference to, and as shown in Figure 6a, 6b and 6c of the accompanying drawings.

18. A method method for storing copies of a data packet as hereinbefore described with reference to, and as shown in Figures 9 and 10 of the accompanying drawings.

19. A method method for extracting or decoding and extracting copies of a data packet as hereinbefore described with reference to, and as shown in Figure 11 of the accompanying drawings.

Intellectual

Property

Office

Application No: GB1616148.1