EP4305781A1 - Procédé de communication et abonné de communication - Google Patents

Procédé de communication et abonné de communication

Info

Publication number
EP4305781A1
EP4305781A1 EP22712568.9A EP22712568A EP4305781A1 EP 4305781 A1 EP4305781 A1 EP 4305781A1 EP 22712568 A EP22712568 A EP 22712568A EP 4305781 A1 EP4305781 A1 EP 4305781A1
Authority
EP
European Patent Office
Prior art keywords
information
coding
packet
communication
header
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22712568.9A
Other languages
German (de)
English (en)
Inventor
Jürgen HUPP
Oliver Haala
Andreas Frotzscher
Hannes ELLINGER
Stefan Lipp
Frank Burkhardt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Publication of EP4305781A1 publication Critical patent/EP4305781A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0076—Distributed coding, e.g. network coding, involving channel coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • Embodiments of the present invention relate to a communication method and to a communication participant, such as a transmitter (transmitter) or a receiver (receiver) or a transceiver, and to a corresponding system with one or more communication participants.
  • a communication participant such as a transmitter (transmitter) or a receiver (receiver) or a transceiver
  • Preferred exemplary embodiments relate to a method for efficient network coded cooperation in real-time radio systems or to network coding in general.
  • FIG. 1 shows an exemplary radio system consisting of five radio nodes 10A to 1QD.
  • nodes are sensors or actuators in moving scenarios, such as (motor) controls.
  • sensors or actuators in moving scenarios or (motor) controls are sensors or actuators in moving scenarios or (motor) controls.
  • Time Division Multiple Access TDMA Time Division Multiple Access
  • Scheduling methods or time-division multiplex methods are usually used in order to implement a deterministic time behavior in radio transmission. In the case of error-free transmission, this leads to a deterministic latency or cycle time. If the transmission is disrupted, action must be taken. However, these measures must not violate the time requirements for the transmission, since external control systems would otherwise react to the transmission disruption, for example with emergency operation or by shutting down the machine.
  • Cooperative Communication CC Relaying and cooperative procedures (Cooperative Communication CC), i.e. packet forwarding by other radio nodes (FK) as forwarding intermediate nodes. Path redundancy also results via this intermediate node.
  • FK radio nodes
  • Such cooperative communication is shown, for example, in FIG. 2a.
  • Figure 2a shows multiple transmitters 10S1 to 10SM transmitting a data packet to a receiver 10E.
  • a number of relay nodes 10R1 to 10RN are also provided in between.
  • the transmitters 10S1 to 10SM (source nodes) transmit the data packet in M (orthogonal) resource blocks (time and/or frequency blocks).
  • the N relay nodes 10R1 to 10RN forward this information to 10E (solid red lines).
  • each relay node requires M orthogonal resources to transmit its transmission vector bRi, which is a vector of length M.
  • this process represents an indirect (cooperative) transmission of the data stream from 10S1 to 10E.
  • the resulting data stream is illustrated in FIG. 2b.
  • the relay nodes 10R1 to 10RN carry out, for example, NC or NCC and send in N resource blocks in order to forward the data packet to the recipient 10E (sink).
  • the transmission vectors bR1, bR2 and bRN (cf. FIG. 2b) are significantly compressed by the Network Coded Cooperation NCC (cf. bR1, bR2, bRN in FIG. 3b), with the transmission vectors bRi continuing to consist of the information signals from Source nodes are transmitted are generated. If the options on a link have been exhausted via channel coding, CC and in particular NCC offer great potential, since this increases the so-called diversity order (number of propagation paths) of the overall system.
  • this NCC signaling overhead represents a problem to be solved.
  • NCC describes a procedure in which data packets are encoded before being forwarded by a router.
  • Several data packets (number n) are each weighted with coefficients (so-called coding coefficients) and added.
  • coding coefficients coefficients
  • algebra is used in finite fields and multiplication/addition in Galois fields with a size/symbol length of g bits is used.
  • FIG. 4 illustrates an exemplary calculation of a coded packet based on two source packets (source data packet 1, source data packet 2). Each source data packet is multiplied by a corresponding coding coefficient C1 or C2 and added up (XOR operation). The concatenation of the coding coefficients C1 and C2 is called coding vector n*g (size: 2*g bits).
  • coding vector n*g size: 2*g bits.
  • the amount of data g of a coding coefficient in bits depends on the size/dimension of the Galois field used. For Galois fields with characteristic 2, this results in 2 9 coding coefficients.
  • node ID/NID node identity
  • each radio node has a unique NID (we will not go into the assignment of the NID).
  • the example from Fig. 5 also starts from the assumption that the source data packet DATA1 is to be multiplied by the coding coefficient C1 and the source data packet DATA2 is to be multiplied by the coding coefficient C2 in order to then form the coded packet(s). ) (Coded Data) to add up.
  • the encoded packets (payload data packet) are part of a data packet 20 and are provided with the reference number 22 .
  • the header 24 is inserted before the encoded packets. This includes, for example, information regarding data sources and data sinks (e.g. NID1 to NID2) and the associated coding coefficients (e.g. C1).
  • This relevant information is provided with the reference number 24A and essentially defines the boundary conditions for the transmission of DATA 1 (source packet 1) from NID1 to NID2 (cf. reference number KOM1).
  • the header 24 also has the area 24B in which the information (cf. reference symbol KOM2) relating to the transmission of DATA 2 (source packet 2) is transmitted. This in turn contains the relevant information regarding data source N1D1, data sink NID7 and the coding coefficient C2 used.
  • Radio nodes have a short NID (7 bits) as a logical address.
  • eight source packets are to be transmitted in one communication cycle.
  • a generally valid data packet could then have the following form:
  • the payload coded data 22 includes data for presumably eight source packets to be transmitted, which becomes clear from the header 24 .
  • the header includes information about the data source, information about the data sink and the corresponding coding coefficients.
  • Radio nodes have a short NID (7 bits) as a logical address, 1 bit indicates whether the fixed radio node (base station) is an uplink or downlink.
  • eight source packets are to be transmitted in one communication cycle, which corresponds, for example, to a radio system in which a base station communicates with four field devices. A universally valid coded packet would then be (radio node 5 is the base station here, for example);
  • the header 24 only has information about the data source in combination with information about the data flow direction.
  • the coding coefficients are still included for each source packet to be transmitted.
  • the NCC header length would be per encoded source packet:
  • Embodiments of the present invention create a communication method with the central step of transmitting, e.g. forwarding by means of a relay node, of at least one data packet.
  • This has a header and an encoded packet.
  • the encoded packets can be used for the transmission of multiple source packets, e.g. B. between one or more sources and one or more sinks or between a source and one or more sinks in different transmission directions.
  • one coding vector is used for each of the source packets to be transmitted as a coded packet (i.e. one coding vector for each coded packet).
  • At least one piece of relevant information e.g. regarding the coding vector, can also be transmitted in the header.
  • the header derivably contains (comprises) at least one first piece of information relevant to the interpretation of the encoded packet from a group, the group comprising one or more of the following pieces of information:
  • - Coding vector wherein the coding vector is contained separately, contained in an integrated manner, is predetermined or referential, with coding coefficients being assigned to the coding vector.
  • the transmission process includes deriving a second piece of information from the group that is relevant for the interpretation of the encoded packet from the at least one first piece of information, taking into account a piece of preconfigured information.
  • Exemplary embodiments of the present invention are based on the knowledge that by transmitting a coding vector, which is either contained in the header or is referenced by other information, and information regarding the data source and data sink that is directly contained or referenced (ie derivable) is, in combination with a preconfigured information such as coding matrix, scheduling table or request list, the signaling effort can be minimized can.
  • a preconfigured information such as coding matrix, scheduling table or request list
  • a first minimization stage is possible, for example, by combining coding coefficients or CV indices (reference to a coding coefficient or in the coding vector) assigned to one or more communication partners or communication partner pairs in a type of list (request list), so that all coding information required for coding/decoding no longer has to be transmitted in the header.
  • coding coefficients or coding vector(s) assigned to communication processes and/or source packets can be contained in a type of matrix (coding matrix), this matrix being referenced by header information.
  • Each communication partner thus receives the necessary coding or decoding information for the source packets to be transmitted, in particular the preconfigured information, with the scope of the header being minimized by referencing.
  • preconfigured configurations such as a coding matrix, a scheduling table or a request list can therefore be used in order to compress the information content in the header.
  • the coding matrix can contain, for example, a relationship between the coding vector or coding vector index, both of which allow the coding coefficients to be inferred, and numbering of the source packet to be transmitted.
  • a so-called scheduling table can be used in accordance with further exemplary embodiments. From the point of view of the sending radio node (source), this specifies a data sink, for example, depending on a communication process number.
  • a so-called request list can be used according to exemplary embodiments, which, for example, starting from a transmitting node (data source) for different data sinks and/or different communication partners in connection with a corresponding data flow direction, specifies coding vector indices.
  • this request list can also specify an assignment to a corresponding cluster ID. This means that, according to one embodiment, the basic embodiment is expanded such that information that is typically transmitted in the header is only transmitted in a derivable manner, namely by referencing preconfigured information, such as a scheduling table, a request list or a coding matrix.
  • the information regarding the source and destination and/or the information regarding the coding vector is not only contained directly but also indirectly in the header. This makes it possible to get by with one bit per payload part (source data packet) in the minimum case.
  • the communication method can include the step of deriving information in the header from other information in the header or deriving information in the header from other information in the header, taking into account a scheduling table and/or a coding matrix and/or a request -Have list.
  • exactly one coding coefficient can be assigned to each of the plurality of source packets to be transmitted per KV. If, in accordance with further exemplary embodiments, it is assumed that the transmission starts from a fixed communication partner (e.g. a fixed base station or source), additional information regarding a source in the header can be dispensed with. This means that the header only has information about one or more sinks of the payload (encoded packet), possibly together with a direction of transmission.
  • a fixed communication partner e.g. a fixed base station or source
  • the request list explained above is used as follows to derive further information:
  • the request list has information relating to the one or more sources and/or sinks for one or more source packets.
  • the request list can have an association of one or more sources and/or one or more sinks with a corresponding coding vector index.
  • the data packet for at least two transmissions has an uplink transmission and a downlink transmission or at least two planned transmissions between different communication partners. These CV indices can then be included in the request list in corresponding sequential numbering.
  • communication processes for a number of data packets are carried out in a chronological sequence. Ie the The step of transmission or the steps of transmission deriving (in combination) are repeated for one or more (consecutively numbered) communication processes and/or repeated in a time sequence (TDMA) and can therefore be (consecutively) numbered. According to exemplary embodiments, this chronological sequence can be defined in a so-called scheduling table.
  • the scheduling table includes an assignment of communication processes to respective sources and/or respective sinks.
  • the chronological sequence of the communication processes or the scheduling table can have a fixed assignment of time slots to the respective data source(s) (and/or to the respective data sinks).
  • a fixed communication partner and one or more associated sources or sinks can be specified for each communication process.
  • An indication of the direction of transmission is also conceivable here.
  • the coding vector or the desired (i.e. planned and/or expected) coding vector it should be noted that, according to exemplary embodiments, this can be dependent or can be derived from a (consecutive) numbering of the communication processes.
  • This relationship or, in general, the relationship between the communication process (KV) and coding coefficients for a source packet can be stored in a so-called coding matrix, for example.
  • the coding matrix defines a relationship between the communication process and coding coefficients for a source packet.
  • a fixed assignment of a respective fixed coding coefficient to a respective communication process and a coding vector index is defined in the coding matrix, with the header containing information regarding the coding vector (CV) as to whether a source packet (assigned to a coding vector index ) is contained in the data packet (20) (cf. extension 1 below).
  • CV coding vector
  • the coding vectors are defined per data source-data sink pair or generally per data source and/or per data sink, possibly in combination with the transmission direction.
  • a coding vector index ie for example a line index (reference to a desired coding vector) can be provided in the header and/or in a coding matrix.
  • This coding vector index is specified for each communication process, for example, or can be derived directly from the respective communication process, and a desired coding vector can in turn be derived from this coding vector index using the coding matrix (For example, if the request list and/or scheduling list and/or coding matrix is known).
  • a so-called compressed (loss-free compressed) encoded data packet is then created.
  • the header only has information relating to one source for each source packet to be transmitted. This enables, for example, the sink to be derivable from the information regarding the source when using, for example, the request list and/or the scheduling table and/or the coding matrix.
  • the scheduling table has information relating to a sink.
  • a clustering of a number of requests between a number of sources and a number of sinks or between a source and a sink in different transmission directions is conceivable.
  • the different clusters can be identified in the request list, thereby enabling individual source/source pairs to specify the type of involvement of these nodes in a communication process in order to advantageously reduce the CV length, since e.g. the same CV can be reused for different clusters can be.
  • This means that the request list is supplemented by an assignment that assigns a cluster to each request.
  • the communication partners exchange or distribute preconfigured information, such as a scheduling table and/or coding matrix and/or request list.
  • preconfigured information such as a scheduling table and/or coding matrix and/or request list.
  • the transmitter and/or receiver can be configured on the basis of the scheduling table and/or coding matrix and/or request list. This is advantageous because the information in the header is reduced and everyone uses the same preconfigured data.
  • the transmission is carried out by a sender or during sending / forwarding.
  • the sending can include the sub-steps of encoding the payload using an encoding vector and/or generating the header.
  • the following sub-steps are also included: • reading out a coding vector specified (planned) for the current communication process from a coding matrix;
  • the communication method is now reduced to receiving, this can therefore be part of what is received or can be carried out by a receiver.
  • the communication method also has the following steps, for example:
  • each communication partner checks, for example after configuration, whether it is involved in the communication process.
  • a further exemplary embodiment relates to a data packet with a header, the header including the information relevant to the interpretation explained above in a measurable manner (eg by reference to other information exchanged in advance).
  • a further exemplary embodiment relates to a communication partner, in particular a sender or relay or in particular a receiver.
  • the communication partner is designed to transmit at least one data packet with a header and a payload/encoded packet(s), the header having the following information in a derivable manner:
  • the coding vector being contained separately, contained in an integrated manner or is specified; coding coefficients being assigned to the coding vector.
  • the communication partner is designed to extract information from the header from other information in the header, taking into account preconfigured information.
  • Communication participants can of course also be transmitters and receivers together. This means that each communication participant has a transceiver with a receiver and a transmitter.
  • UEs or ioT devices or the like are used as communication participants.
  • a further exemplary embodiment relates to a communication system with at least one communication participant who acts as a sender and one communication participant who acts as a receiver.
  • the communication system can also include a plurality of communication participants.
  • the developed method can be used for deterministic communication systems with low latency, ie the communication between the nodes takes place within one communication cycle.
  • the radio nodes communicate directly with one another, that is to say they all tend to be within radio range of one another. This allows the so-called overhearing effect to be used.
  • radio nodes can also receive data packets that are not intended for them, but actually for other radio nodes, and then forward them.
  • the number of participants and the amount of data per communication cycle exchanged between the radio nodes can be configured and can also be changed at runtime.
  • a spontaneous, rapid change in the time range of the communication cycle is not mandatory.
  • the method when transmitting at least one data packet (20) includes forwarding a source packet from a source (further nodes) or forwarding multiple source packets from multiple sources (further nodes).
  • the forwarding is carried out, for example, by a repeater node.
  • it can include forwarding a received data packet from one source or forwarding multiple received data packets from multiple sources.
  • Recoding takes place here, i.e. the forwarding includes coding using a further coding vector (e.g. different compared to the received data packet(s)).
  • 1 shows a schematic radio system to illustrate the area of application
  • FIGS. 2a and 2b show a schematic diagram to illustrate cooperative communication
  • 3a and 3b show a schematic diagram to illustrate cooperative communication using network coding
  • 4 shows a schematic diagram for explaining a calculation in network coding
  • FIG. 5 shows a schematic diagram for explaining the contents of a header in network coding
  • 6a shows a schematic representation of a communication system for explaining a basic exemplary embodiment
  • 6b shows a schematic representation of a header according to a basic exemplary embodiment
  • FIG. 7a-7i show schematic representations for explaining the interaction of request list, scheduling table and coding matrix in order to code or decode a transmission matrix according to exemplary embodiments;
  • FIG. 8 shows a schematic representation to illustrate a process within a radio node at the start of a communication cycle according to an extended exemplary embodiment
  • FIG. 9 shows a schematic block diagram to illustrate processes within a radio node at the start of a communication process according to an extended exemplary embodiment
  • FIG. 10 shows a schematic block circuit diagram to illustrate processes within a radio node when transmitting according to an extended exemplary embodiment
  • 11 shows a schematic block diagram to illustrate processes within a radio node when receiving according to extended exemplary embodiments
  • 12 shows a schematic block diagram to illustrate processes within a radio node at the end of a communication cycle according to an extended exemplary embodiment.
  • Fig. 6a shows a communication network 30 with a transmitter 32 and a receiver 34.
  • the transmitter 32 sends the encoded data packet 20 to the receiver 34.
  • the transmitter 32 includes a header generator 32H and a network coding encoder 32e.
  • the network encoder 32e is designed to decode a source packet SP using coding coefficients in order to obtain an encoded data packet.
  • two or more source data packets SP can be folded with one another, so that the two or more packets combined in the coded packet are transmitted in a common resource.
  • the multiple packets are separated by the receiver 34 using the coding vectors CV used. This approach makes it possible to forward multiple data packets (e.g. from multiple sources) to multiple sinks with "one" resource.
  • the receiver or receivers 34 receive the coding coefficients via the coding vector CV, for example.
  • This coding vector CV is also integrated into the header.
  • the process of integrating the CV into the header 24 is done by the header generator 32H.
  • This header 24 is part of the data packet 20 emitted by the encoder 32e.
  • the data packet 20 also includes the encoded data packet(s) (cf. payload 22).
  • the encoder 32e includes a number of units, such as an actual decoder for the encoded data packets 22 and a packer, which combines the encoded data packets 22 and header 24 into the data packet 20 .
  • the encoded data packets 22 can include a plurality of source packets to be transmitted. For example, an uplink from 32 to 34 and a downlink from 34 to 32 can be planned. Several source packets to be transmitted for more than the two communication partners 32 and 34 shown can also be integrated in the same data packet.
  • the transmitter 32 can send an encoded data send packet to the receiver 34, while together with the same encoded data packet 22 another encoded data packet for another receiver (not shown) is included.
  • Receiver 34 receives data packet 20 and encodes data packet 20 using decoder 34d.
  • the encoder typically uses the coding vector or the coding coefficients derived from the coding vector. He receives this with the help of the header.
  • the receiver 34 has a header decoder 34H, which extracts the relevant coding vector CV from the header 24 and makes it available to the decoder 34d.
  • the information in the header 24 is transmitted in reduced form, as is shown with reference to FIG. 6b.
  • the header contains less information than is actually necessary for the transmission.
  • information relating to the one or more data sinks (receivers) can be present in the header.
  • information regarding the one or more data recipients can also be present.
  • the coding coefficients are not also transmitted in the header, only a coding vector. The coding coefficients can then be determined from this, as will be explained below.
  • only CV indices that are referenced in an additional data package e.g. information transmitted in advance or preconfigured information, are included.
  • the complete information required for the encoding/decoding can be derived using the pre-configured information such as the request list 42, encoding matrix 44 and/or scheduling table 46.
  • the method can include the step of exchanging preconfigured information in advance.
  • the method also includes the step of deriving further information from information taken from the header using the preconfigured information.
  • both the header generator 32H and the header decoder 34H for generating and unpacking the header 22 and/or also the header encoder 34e for encoding use the preconfigured information.
  • These preconfigurations 42, 44 and 46 can be sent in advance by the transmitter 32 to the receiver 34 are transmitted.
  • the decoder 32d can also use information derived from the preconfigured information, namely the actual coding vector.
  • the data packet 20 has a header 24 as shown with respect to FIG. 6b.
  • This header 24 can include information for three source packets to be transmitted, for example. These are marked with reference numerals 24A, 24B and 24C. All user data for the three source packets to be transmitted is shown in the payload / the encoded data packets.
  • a data source A, a data sink B and the corresponding communication vector are shown in the area assigned to the source packet 24A.
  • a data source B, a data sink A and the corresponding coding vector are contained for the source packet 24B to be transmitted.
  • 24A can define an uplink process while 24B can define a downlink process.
  • Another data sink C can be provided at 24C, for example.
  • a respective coding vector is assigned for each of these source packets to be transmitted, defined via data source and data sink.
  • the signaling effort can be reduced by using the coding vector, since the corresponding coding coefficients no longer have to be transmitted. These are derived from the coding vector.
  • the header parts for the first two source packets to be transmitted can also contain only the information relating to sink B, and information can also be included that the source packet to be transmitted is Package is an uplink and the other source package to be transmitted is a downlink process. The whole thing is based on the assumption that the header is written from the point of view of communication partner A. In this case, the data transfer C would then be defined by information “uplink” and data sink C.
  • the coding vector can be derived, for example, from a coding matrix, with the coding matrix containing information relating to the coding vectors used assigned to communication processes (numbered communication processes) or assigned to communication processes. communication partners (e.g. data sink).
  • communication partners e.g. data sink.
  • the CV indices and/or requests can be assigned to the columns of the coding matrix and the KVs to the columns.
  • Figure 7a is through the communication link between a base station 10S and three nodes 10E1-10E3.
  • Base station 10S has NID 5
  • receivers 10E1-10E3 are numbered NIDs 7, 2, and 3.
  • the communication links between the respective elements are marked with capital letters A, B and C for the downlink and a, b and c for the uplink.
  • This list shown in FIG. 7c is valid for one communication process, ie for one time slot.
  • several communication processes can take place in consecutive time slots. These are shown as an example in the scheduling table from FIG. 7d.
  • the base station transmits in the first three communication processes, while in the communication processes 7, 8 and 9 the communication from the point of view of one of the nodes 10E1-10E3 is looked at.
  • the corresponding coding vector or also a coding vector index can also be taken into account via this large number of chronologically consecutive communication processes, which e.g. is referenced in the coding matrix.
  • the encoding matrix is shown in Figure 7e.
  • the coding matrix illustrates the respective value for the corresponding transmission process A, B, C, a, b, c via the individual communication processes KV1-KV13.
  • a downlink transmission B is carried out in the communication process KV1
  • a downlink transmission A is carried out in the communication process KV2 (cf. FIG. 7a).
  • Figure 7f shows the coded packets according to the coding matrix over the corresponding communications 1-10. Taking this coding matrix into account, a header can then be determined for each communication process, which has a reduced content overall.
  • FIG. 7g The full header that is typically to be transmitted for communication process KV3 is illustrated in FIG. 7g.
  • communication A and B is made possible (cf. FIG. 7e or 7f) from the point of view of the base station (cf. scheduling table from FIG. 7d).
  • the source NID is 5
  • the destination NID is 7 or 2.
  • the corresponding coding coefficients for A and B are 1, as can be seen from FIG. 7e.
  • this comprehensive header from FIG. 7g can be reduced by using the preconfigured information request list, scheduling list and/or coding matrix, as shown for example in FIG. 7h.
  • FIG. 7h shows a reduced header in which the coding coefficients or CV indices are inserted starting from the first request list from FIG. 7b.
  • the header in accordance with a first compression level, can be reduced in size by using the request list, since it does not have to contain either the source or the sink. Further miniaturization is possible as shown in relation to Figure 7i.
  • FIG. 7i also uses the coding matrix, so that only one bit needs to be used to indicate whether or not a corresponding data packet is contained.
  • the preconfigured information includes, for example, the request list, a scheduling table and/or a coding matrix. Examples of such preconfigured information are also discussed in detail below.
  • a request refers to a source data packet which is to be transmitted from a radio node as the data source (source) to a radio node as the data sink (destination). Source/destination are described via their node identity. Multiple data packets between the same source/destination radio nodes are handled as multiple requests. A request list with request indices can be generated from this. At this point it should be noted that the request is typically defined at the application level.
  • An index in the coding vector (CV) is uniquely assigned to each request.
  • the coding coefficient is entered at the point described by the CV index.
  • the coding coefficient C NID5->NID2 for data packet from source NID5 to sink NID2 is signaled under CV index 2
  • the coding coefficient CNID2->NID5 for data packets from source NID2 to sink NID5 is signaled under CV index 6
  • Table 1 Request list with any radio node as source/destination
  • Example of request list 2 communication between a fixed radio node as a base station and other radio nodes :
  • UL/DL can also be used instead of Src/Dest.
  • Table 2 Request list with a fixed radio node as base station and other radio nodes
  • the CV index can also be derived directly from the NID. This procedure is useful when the number of participating nodes is small and the NIDs are assigned consecutively numbered in the network so that all positions in the CV are occupied.
  • Table 3 Request list with a fixed radio node as base station and other radio nodes and link between NID and CV index
  • the above request lists have in common that for a communication partner pair, e.g. B. defined via a sink in combination with a flow direction or for a data source in combination with a data sink, a coding vector is specified or referenced. scheduling list
  • the scheduling table describes the chronological sequence of communication operations (KV) within a finite time frame and specifies the nature of the involvement of each FK to the respective KV.
  • the KVs are numbered consecutively (1, 2, . . . n KVs ), where n KVs denotes the total number of all KVs in the scheduling table.
  • An existing assignment between transmission slots and FK in a TDMA system can be adopted.
  • Table 4 Scheduling table with specification of the transmitting radio node
  • the scheduling list makes it possible, so to speak, to allocate communication processes in a chronological order.
  • the communication processes are identified, for example, based on the data sources.
  • the coding matrix defines which source data packet is to be coded into the coded packet of a specific KV according to the request list.
  • “1” here designates a non-zero coding coefficient, ie the information of the corresponding source packet should be contained in the coded packet.
  • the coding coefficient actually used for the weighting of the source packet can be specified in the coding matrix in the case of systematic linear network coding (instead of “1” then with “1” to “2 g -1” depending on the Galois field size). Alternatively, any coding coefficient newly selected for each KV can be used. This allows a random linear network coding to be signaled efficiently. In this method, the coding coefficients are generated using random methods.
  • the three preconfigured items of information, coding matrix, scheduling table and request list, are preferably used together, as explained below.
  • the encoded packet can be transmitted in compressed form using the three lists as a data basis in each node (data source, data sink or relay). This results in the following compressed data package, for example:
  • the NCC header length would then be the Coeff length (corresponding to the Galois field dimension), e.g. 4 bits.
  • the Coeff length corresponding to the Galois field dimension
  • Coeffxy means that for the KV x the source packet that is referenced at the position of the CV index y should be weighted with this coding coefficient.
  • the compressed, encoded packet then only has to state whether the relevant source packet is actually contained, which corresponds to the 1-bit logical information.
  • the NCC header length would then only be the number of coding coefficients in bits.
  • the CV becomes long, which creates header overhead.
  • the processing time for encoding and, above all, decoding increases sharply.
  • clusters can be formed.
  • the table from example 1 has been extended to include clusters. This allows the CV indices to be assigned per cluster.
  • the scheduling table can also be expanded in accordance with further exemplary embodiments. Scheduling table with Destination NID specification. This can limit overhearing, e.g. to save energy.
  • Scheduling table with Destination NID specification This can limit overhearing, e.g. to save energy.
  • these expanded elements of scheduling table, request list and coding matrix can be used either together or individually in combination with the basic variants.
  • all FKs of the communication system are configured using the configuration information, in particular the request list, scheduling table and coding matrix.
  • a configuration phase before the operating phase (initialization) or between operating phases in the event of changes in the network topology (reconfiguration) can be provided. Radio communication between the nodes can be used for configuration.
  • each FK then receives the corresponding configuration parameters (request list, scheduling table and coding matrix).
  • each FK internally determining the number of KVs that have already been completed within a cycle, for example using an internal counter or a timer.
  • the state of the network coding encoder/decoder is reset so that it no longer contains any coded packets from previous communication cycles.
  • Each FK then uses its NID to check which source packets it should send within this cycle according to the request list.
  • Each source packet to be sent is fed into a network coding decoder as a CV together with the i-th unit vector e i , with i corresponding to the CV index of the request. This is illustrated by way of example with reference to FIG. 8 .
  • Packet SP is decoded by network coding encoder 32e in the transport layer. For this purpose, it receives the coding vectors CV from the unit vector generator 32EV. Coding vector indices from the request list can be used as input, with the 42 being the own NID 32-1D as the input parameter for the request list. This therefore means that the corresponding CV indices are contained with its own NID from the request list, with the unit vector generator 32E deriving the coding vector. According to exemplary embodiments, the unit vector generator 32E can be used for the coding matrix 46 here.
  • each FK checks whether it is actively (sending), passively (receiving) or neither actively nor passively (only in the case of expansion 2/3) involved in the KV according to the scheduling table (cf. FIG. 9).
  • Fig. 9 illustrates the transport level once again, specifically when the scheduling table is used by the KV determiner 32.
  • Network coding encoder checks whether the FK knows the source packets associated with the CV indices of the desired CV. For all CV indices with associated known source packets, the coding coefficients of the actual and the desired CV match. For all CV indices associated with unknown source packets, the coding coefficient of the actual CV is used Assigned a value of zero (e.g. if a packet was not received and therefore cannot be forwarded). If, for example, the transmission of three source packets is planned with CV 513, but the second source packet cannot be received and therefore cannot be forwarded, the planned CV results in 513 and an actual CV of 503.
  • Network Coding Encoder calculates the payload of an encoded packet. The coding is based on the actual CV.
  • Header Encoder creates a header from the actual CV. a. Without extension 1, the header and the actual CV are identical. b. With extension 1, the header and the compressed CV described in extension 1 are identical.
  • the packer forms an encoded packet from the header and the payload.
  • FIG. 10 shows an extension of the transport level with the network encoder 32E.
  • This in turn retains a coding vector as an input vector, which z. B. is derived from the coding matrix 46, with the KV determiner 32K serving as an input parameter for the coding matrix.
  • the payload is then correspondingly encoded by this encoder 32E and transferred to the packer 32V.
  • This combines the header from the header encoder or header generator 32G with the encoded payload.
  • the header encoder receives the coding vector used from the encoder 32E as an input parameter for the header.
  • FIG. 11 now shows the process of receiving the encoded packet 20 (cf. output of the packer 32V) or input (unpacker 34P), which is connected to the decoder 34d.
  • the data packet 20 is unpacked in the receiving section (cf. 34P), with the header and payload/encoded data packet then being supplied separately to the decoders 34H and 34D.
  • the header decoder extracts the coding vector, which is used as an input parameter for the network coding decoder 34D.
  • the header decoder 34H uses the coding matrix 46 as an input parameter, which in turn receives the communication process number from the KV determiner 34K as an input parameter. This results in the following process with the four steps 1 to 4 and the optional steps 3A and 3B
  • Header Decoder reconstructs the actual CV from the desired CV and the header. a. Without extension 1, the actual CV and header are identical. b. With extension 1, the actual CV is calculated by multiplying the header and the desired CV element by element.
  • Network Coding Decoder processes the actual CV along with the payload.
  • each FK uses the request list and its NID to check which source packets or CV indices are intended for it.
  • An associated unit vector is formed for each of these CV indices, the i-th unit vector e i being assigned to a CV index i.
  • the unit vectors are fed sequentially into the network coding encoder (Errorl Reference source could not be found. 12).
  • the request list 46 receives the NID in order to determine the CV index from this.
  • the unit vector generator 32E determines the coding value on the basis of the CV index and makes this available to the network coding encoder 32E. From this, the latter encodes the encoded data packets into the source packet and transfers this source packet SP to the application level.
  • Each reconstructable source packet is transmitted to the application layer.
  • Source packets that cannot be reconstructed remain in the network coding encoder and are deleted at the beginning of the next communication cycle.
  • the above approach can be used for radio communication systems that work deterministically in order to support real-time communication and thereby achieve low latency.
  • the scheduling table includes, for example, an assignment of communication participants/nodes to communication processes.
  • the coding matrix includes, for example, an assignment of source data packet to coded data packet and can include coding vectors for the individual communication processes.
  • the request list includes, for example, an assignment of CV indices to communication participants/nodes.
  • aspects have been described in the context of a device, it should be understood that these aspects also represent a description of the corresponding method, so that a block or component of a device also counts as a corresponding method step or as a feature of a method step understand is. Similarly, aspects described in connection with or as a method step also constitute a description of a corresponding block or detail or feature of a corresponding device.
  • Some or all of the method steps may be implemented by hardware apparatus (or under using a hardware apparatus) such as a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, some or more of the key process steps can be performed by such an apparatus.
  • a signal encoded according to the invention such as an audio signal or a video signal or a transport stream signal, can be stored on a digital storage medium or can be transmitted on a transmission medium such as a wireless transmission medium or a wired transmission medium, e.g. the Internet
  • the encoded audio signal according to the invention can be stored on a digital storage medium, or can be transmitted on a transmission medium such as a wireless transmission medium or a wired transmission medium such as the Internet.
  • embodiments of the invention can be implemented in hardware or in software. Implementation can be performed using a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory can be carried out on which electronically readable control signals are stored, which can interact with a programmable computer system in such a way or interact that the respective method is carried out. Therefore, the digital storage medium can be computer-readable.
  • a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory
  • the digital storage medium can be computer-readable.
  • Some exemplary embodiments according to the invention thus include a data carrier which has electronically readable control signals which are capable of interacting with a programmable computer system in such a way that one of the methods described herein is carried out.
  • exemplary embodiments of the present invention can be implemented as a computer program product with a program code, with the program code being effective to carry out one of the methods when the computer program product runs on a computer.
  • the program code can also be stored on a machine-readable carrier, for example.
  • exemplary embodiments include the computer program for performing one of the methods described herein, the computer program being stored on a machine-readable carrier.
  • an exemplary embodiment of the method according to the invention is therefore a computer program which has a program code for carrying out one of the methods described herein when the computer program runs on a computer.
  • a further exemplary embodiment of the method according to the invention is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the computer program for carrying out one of the methods described herein is recorded.
  • the data carrier, digital storage medium, or computer-readable medium is typically tangible and/or non-transitory.
  • a further exemplary embodiment of the method according to the invention is therefore a data stream or a sequence of signals which represents the computer program for carrying out one of the methods described herein.
  • the data stream or the sequence of signals can be configured, for example, to be transferred over a data communication link, for example over the Internet.
  • Another embodiment includes a processing device, such as a computer or programmable logic device, configured or adapted to perform any of the methods described herein.
  • a processing device such as a computer or programmable logic device, configured or adapted to perform any of the methods described herein.
  • Another embodiment includes a computer on which the computer program for performing one of the methods described herein is installed.
  • a further exemplary embodiment according to the invention comprises a device or a system which is designed to transmit a computer program for carrying out at least one of the methods described herein to a recipient.
  • the transmission can take place electronically or optically, for example.
  • the recipient may be a computer, mobile device, storage device, or similar device.
  • the device or system may include a file server for interpreting the computer program to the recipient.
  • a programmable logic device eg, a field programmable gate array, an FPGA
  • a field programmable gate array may cooperate with a microprocessor to perform any of the methods described herein.
  • the methods are performed on the part of any hardware device. This can be hardware that can be used universally, such as a computer processor (CPU), or hardware that is specific to the method, such as an ASIC.
  • the devices described herein may be implemented, for example, using hardware apparatus, or using a computer, or using a combination of hardware apparatus and a computer.
  • the devices described herein, or any components of the devices described herein may be implemented at least partially in hardware and/or in software (computer program).
  • the methods described herein may be implemented, for example, using hardware apparatus, or using a computer, or using a combination of hardware apparatus and a computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé de communication qui comprend les étapes suivantes : la transmission d'au moins un paquet de données (20) comprenant un collecteur (24) et d'un paquet codé (22), l'en-tête (24) contenant au moins un premier élément d'informations pertinent pour interpréter le paquet codé à partir d'un groupe, le groupe comprenant un ou plusieurs des éléments d'informations suivants : - des informations concernant une ou plusieurs sources (32) du paquet codé (22) et des informations concernant un ou plusieurs consommateurs (34) du paquet codé (22) ou une information concernant une ou plusieurs sources (32) ou des consommateurs (34) du paquet codé (22) en combinaison avec une information concernant une direction de transmission ou autour d'un ou plusieurs autres partenaires de communication (34) ; - des vecteurs de codage (CV), le vecteur de codage (CV) étant contenu séparément, contenu de manière intégrée, prédéfini ou référencé, le vecteur de codage (CV) étant attribué à des coefficients de codage ; et le calcul d'un second élément d'informations pertinent pour interpréter le paquet codé du groupe à partir de l'au moins un premier élément d'informations, en prenant en considération une information préconfigurée d'informations.
EP22712568.9A 2021-03-12 2022-03-10 Procédé de communication et abonné de communication Pending EP4305781A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21162296.4A EP4057533A1 (fr) 2021-03-12 2021-03-12 Procédé de communication et abonné de communication
PCT/EP2022/056167 WO2022189561A1 (fr) 2021-03-12 2022-03-10 Procédé de communication et abonné de communication

Publications (1)

Publication Number Publication Date
EP4305781A1 true EP4305781A1 (fr) 2024-01-17

Family

ID=74873570

Family Applications (2)

Application Number Title Priority Date Filing Date
EP21162296.4A Withdrawn EP4057533A1 (fr) 2021-03-12 2021-03-12 Procédé de communication et abonné de communication
EP22712568.9A Pending EP4305781A1 (fr) 2021-03-12 2022-03-10 Procédé de communication et abonné de communication

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP21162296.4A Withdrawn EP4057533A1 (fr) 2021-03-12 2021-03-12 Procédé de communication et abonné de communication

Country Status (4)

Country Link
US (1) US20230422093A1 (fr)
EP (2) EP4057533A1 (fr)
CN (1) CN117136513A (fr)
WO (1) WO2022189561A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113381838A (zh) * 2020-03-09 2021-09-10 华为技术有限公司 数据传输方法及通信装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US964780A (en) 1909-09-27 1910-07-19 Timothy L Holland Hat-fastening.
WO2014134276A1 (fr) 2013-02-28 2014-09-04 Aalborg Universitet Procédé, appareil et protocole d'amélioration de performance dans un réseau sans fil
WO2014159616A2 (fr) 2013-03-14 2014-10-02 Aalborg Universitet Procede et appareil pour ameliorer des protocoles de routage dans des reseaux mailles sans fil
US10270468B2 (en) 2014-12-19 2019-04-23 Aalborg Universitet Method for file updating and version control for linear erasure coded and network coded storage
US9967909B2 (en) * 2015-11-04 2018-05-08 Motorola Mobility Llc Wireless ad hoc network assembly using network coding
WO2017095282A1 (fr) 2015-12-02 2017-06-08 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et agencements pour mettre en oeuvre un codage de réseau amélioré
US20190386774A1 (en) * 2016-12-02 2019-12-19 Harman International Industries, Incorporated Communication Method and System
WO2020210682A1 (fr) * 2019-04-12 2020-10-15 Apple Inc. Codage de réseau au niveau de la couche de protocole de convergence de données par paquets (pdcp) pour augmenter la fiabilité de communication

Also Published As

Publication number Publication date
WO2022189561A1 (fr) 2022-09-15
EP4057533A1 (fr) 2022-09-14
CN117136513A (zh) 2023-11-28
US20230422093A1 (en) 2023-12-28

Similar Documents

Publication Publication Date Title
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE602005005031T2 (de) Kommunikationsrelaiseinrichtung
DE60316094T2 (de) Verfahren, Vorrichtung und System für die Komprimierung von verlängerten Kopffeldern
EP2115948A1 (fr) Procédé et équipement de transmission optimisée des données entre un dispositif de commande et plusieurs appareils de terrain
DE102011015966B4 (de) Automatisierungssystem
WO2022189561A1 (fr) Procédé de communication et abonné de communication
EP3343303B1 (fr) Système de radiocommunication pour un système d'automatisation industrielle et son procédé de fonctionnement
DE102012206529A1 (de) Drahtloses Echtzeitübertragungssystem
DE102010000995B3 (de) Erhöhung der Echtzeitfähigkeit von Ethernetnetzwerken
EP1511215B1 (fr) Procédé et dispositif de transmission de données selon un procédé ARQ hybride
EP3744021B1 (fr) Station d'abonné pour un réseau de communication en série et procédé de correction des erreurs uniques dans un message d'un réseau de communication en série
EP1527578A1 (fr) Communication dans un reseau de donnees
EP3518470A1 (fr) Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé, programme informatique ainsi que support lisible par ordinateur
EP2741453B1 (fr) Procédé de fonctionnement d'un appareil bus d'un dispositif d'automatisation du bâtiment, et appareil de configuration et produit programme d'ordinateur correspondants
DE102013213606B3 (de) Verfahren zum Übertragen von Daten
DE102013215829B3 (de) Verfahren zum Übertragen von Daten
WO2022152848A1 (fr) Réseau de communication
WO2006114391A1 (fr) Systeme de communication
EP3485615B1 (fr) Appareil de bus de terrain destiné à communiquer avec un appareil d'automatisation à distance
EP4080798A1 (fr) Dispositif et procédé d'analyse intrinsèque de la qualité de connexion dans les réseaux radio à coopération codée en réseau
DE102015208926B4 (de) Verfahren zum drahtlosen Übertragen von Daten
DE102013218307B4 (de) Verfahren zum Übertragen von Daten
EP2188951A1 (fr) Procédé et dispositif d'établissement de protocole de connexions de communication pour des taux de transfert très élevés
DE102020201140A1 (de) Verfahren und Vorrichtung zum Automatisieren einer Fahrfunktion
DE102018008721A1 (de) Anbindung eines Endgeräts an einen Datendienst

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230907

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR