Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1101—Session protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/24—Multipath
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
  • H04L47/263—Rate modification at the source after receiving feedback
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/80—Responding to QoS

Definitions

• the present invention relates to a method and a system for transmitting a multimedia data stream from one or more transmitters to one or more receivers, through a transmission network.
• this method is directed to a method and a system for transporting video data over a communication network using the Internet Protocol (IP).
• IP Internet Protocol
• the field of the invention is the field of telecommunications and in particular telecommunications applied to the field of multimedia.
• the invention applies more particularly to the transport of multimedia data over an Internet type communication network using the IP protocol.
• the multimedia data concerned are in particular the sound and / or the moving image. In fact, broadband IP links are becoming more widespread in Europe,
• IP Internet Protocol version 4
• IPv6 Internet Protocol version 6
• RTP stands for Real-time Transport Protocol, transport level protocol (level 4 in the OSI model). Although protocol of the transport layer, this protocol adds a number of application functions, such as the transport of the reference clock for example. It has been designed to carry real-time streams, typically audio and video, over IP networks.
• RTP / RTP Stream This is a notion equivalent to the RTP session defined in [RTP]. This is an RTP stream defined by a couple of addresses of source / destination transport each defined by an IP address / UDP port pair.
• Transport Address / Transport Address The origin or destination of a UDP or RTP data stream in our environment. Defined by the pair of IP address / port (UDP, User Datagram Protocol or TCP, Transmission Control Protocol).
• Transport Stream or TS this is the format commonly used in the field of digital television for the transport of multiplexed audiovisual data streams.
• the TS format is defined in [ISO 13818-1].
• Encoder Equipment for digitizing (if necessary), compressing and encoding audio and video data.
• Decoder Equipment for decoding, decompressing and formatting (analog for example) compressed audio and video streams.
• RTT Round Trip Time: The time it takes for a packet to pass through the network to reach its destination.
• stream refers to any stream of data or stream of packets if the data is packaged.
• stream fragment refers to a portion of the data or packets of an original stream, possibly encapsulated in another data or packet format.
• bit rate of the access links in particular xDSL (xDSL: any type of DSL) in the "upload” direction (user to network) is generally very limited.
• the new VDSL technologies will allow in their most common deployment a flow of 2Mb / s only for "upload”.
• IP networks, especially xDSL still have packet loss rates higher than what is commonly observed on Telecom networks, especially if we are talking about the Internet and its packet loss rates remain too high. important for professional video transport.
• An object of the invention is thus to provide a method and a system for increasing the transmission rates of multimedia signals over IP. Another object of the invention is to provide a method to ensure a greater guarantee of routing and greater continuity of operation than current systems.
• the invention proposes to remedy the aforementioned problems and to achieve the objectives noted above, by a method of transmitting a multimedia data stream from at least one transmitter to at least one receiver through at least one link comprising at least one IP type communication network, said method comprising the following steps:
• the link between the transmitter and the communication network, or between the communication network and the receiver comprises a plurality of physical paths. These paths can carry packets in parallel.
• the connection of each physical path to the network can be achieved through, for example, modem-type means.
• the invention thus makes it possible to exceed the flow limits imposed by a single connection line.
• the user can therefore achieve the desired rate by multiplying the number of physical path between the transmitter and the network or between the network and the receiver.
• the method can be implemented to achieve a transmission of a multimedia data stream in real time, with integrated jitter processing and very low latency.
• connection between the receiver and the network or between the transmitter and the network consists of a plurality of physical paths makes it possible, in particular, to use at least a portion of the available bit rate of the lines as a backup each other, which increases the guarantee of routing and continuity of operation of the system arranged to implement the method according to the invention.
• the method according to the invention may further comprise a splitting (I) of the multimedia data stream (F) constituting a partition of the packets of said stream in at least one set said fragment containing at least one packet.
• the splitting of the flow is carried out at a rate adjusted according to at least one parameter, called weight, determined according to at least one data selected from the following list: initialization parameter, transmission quality indicator, flow rate relative to another operation.
• weight determined according to at least one data selected from the following list: initialization parameter, transmission quality indicator, flow rate relative to another operation.
• the method according to the invention may, in particular, comprise a distribution of the data stream over a plurality of physical transmission paths, as a function of information relating to at least one transmission path.
• the purpose of this distribution is to distribute the multimedia data stream between a plurality of physical paths according to distribution constraints.
• the distribution can take into account the total rate to be conveyed and the transmission rates on each transmission line, and then distribute the multimedia data stream to be transmitted between the different transmission lines.
• Other constraints such as flow rates mini ⁇ naux or maxims fixed by a user, can be taken into account during this distribution.
• the splitting of the multimedia data stream into a plurality of stream fragments and / or the distribution of data packets over a plurality of paths may for example be performed by a scheduler using weighted Round Robin scheduling.
• This scheduling is well known to those skilled in the art.
• Data packet splitting can be dynamically adjusted based essentially on at least one fixed or variable effective rate of transmission over at least one path. Indeed, the actual transmission rates may vary at each line. This variation can lead to an adjustment of the fractionation according to new values of flow rates obtained after variation.
• the data packet splitting can be dynamically adjusted based essentially on at least one transmission jitter value on at least one path.
• values may advantageously complete the list of values allowing the dynamic adjustment of the fractionation.
• this can be the packet loss rate or the packet reordering rate.
• the packetization step may comprise at least one encapsulation of the data in a Real Time Protocol (RTP) compliant packet on at least one path.
• RTP Real Time Protocol
• This encapsulation can be specific to each path. Using this format allows you to:
• the method may comprise sending data packets from the transmitter to the receiver through at least one physical transmission path, the sending being carried out according to a variable bit rate. transmitting data on said transmission path.
• the sending of packets from the transmitter to a receiver through the transmission network can be achieved with a send rate smoothing.
• This flow smoothing or "traffic shaping” can be achieved on the basis of conventional algorithms, for example "token bucket filter”, well known to those skilled in the art.
• the method according to the invention may comprise a transmission of data packets from the transmitter to the receiver, through a plurality of physical paths, each of these physical paths being addressed by the transmitter by means of a or multiple IP addresses (Internet Protocol).
• IP addresses Internet Protocol
• the data packets are ready to be sent to the transmission network to be transmitted to the receiver, they are sent by the transmitter to a plurality of physical paths that link the transmitter to at least one network of transmitters. transmission.
• These physical paths which can carry data packets in parallel, are addressed by the transmitter using a destination IP address, a UDP port, a network interface and a gateway IP address. access to the network if necessary (depending on the network architecture). With these addresses, the transmitter sends on each physical path the packets that must be conveyed by these paths to be injected into at least one transmission network.
• the method according to the invention may further comprise receiving, by the receiver, data packets on a plurality of physical paths, each of these physical paths leading to a pair (IP address, UDP port).
• the data packets that are sent by the transmitter over a plurality of physical paths by means of a plurality of network interfaces, to the receiver through the transmission network are received at the receiver on one or more several paths each having at least one network interface.
• Each path ends, in particular, on a couple (IP address, UDP port). This is what differentiates the different paths at the reception.
• a reception of a new packet is followed by a scheduling of this packet in a queue according to information relating to the new packet received and / or at least one packet previously received.
• the information taken into account during such a scheduling can for example be the SN "Sequence Number" or the TS "Timestamp" of the RTP packet.
• Packets can be scheduled in a waiting girl that is specific to each physical path of reception or on a queue common to one or more receive paths. During this scheduling, it may be possible to perform correction operations on the received data packets, such as the deletion of duplicate packets, for example.
• the latencies on all the paths are not necessarily the same, the queue or queues in which the packets are scheduled can compensate for a possible latency and thus allow the data streams of the different paths to be re-phased. facilitate the recomposition of the original stream.
• the information contained in the data packets can be used in reception to, for example, synthesize a local clock, image of the clock in transmission. synthesized can be used to slave the receiver output rate and suppress jitter.
• the method according to the invention may comprise a reassembly of a plurality of packets received on a plurality of physical link paths between the transmission network and the receiver, said packets being selected on said plurality of functional paths. information they contain.
• the selection of a packet for example in a path-specific ordered packet of packets, can be done according to the original order number (SN in the RTP case) of the data packet.
• the method according to the invention makes it possible not to take into account instantly the SN of the packet. This also alleviates some problems, such as packet loss problems for example.
• the invention may advantageously include a multimedia data extraction of at least one received packet.
• This extraction makes it possible to extract the data of the original multimedia data stream from a packet in which this multimedia data could possibly have been encapsulated.
• the original data can then advantageously be inserted into an output queue, to reconstitute the original multimedia data stream.
• the method according to the invention may comprise a reordering of these data in the output queue.
• the method according to the invention may advantageously comprise an output of the data of the original multimedia data stream to another equipment.
• the data can for example be extracted from an output queue and sent to the equipment in question.
• This operation may, in a particular embodiment, be performed by a module for jitter suppression and output rate control.
• the method according to the invention may comprise an adaptation allowing formatting of the data of the multimedia data stream to be transmitted according to at least one predefined format.
• This adaptation can be performed at the input of the transmitter to format the original multimedia data stream to be transmitted in accordance with a format predefined and / or output of the receiver for formatting the multimedia data stream output of the receiver to send it to a device requiring a particular formatting reception.
• the formatting of the data can be performed at a rate adjusted according to at least one parameter chosen from the following list: initialization parameter, a transmission quality indicator (1002), any bit rate.
• an encoder For example, we can control the encoder bit rate of an encoder (MPEG2 for example) according to the parameters mentioned above.
• This encoder can be integrated or not in the transmitter.
• the method according to the invention may comprise in reception a correction of at least one transmission error of multimedia data packets received by means of redundancy data.
• This correction can, in particular be achieved by a correction technique comparable to the FEC ("Forward Error Correction"). Errors that can be corrected are, for example, packet loss or degraded data reception during transmission.
• the transmission of data from the transmitter to the receiver can advantageously include a sending of the transmitter to the receiver, redundancy packets of the multimedia stream to be transmitted.
• This redundancy data may be encapsulated in packets according to a predefined format.
• These redundancy data packets may be any combination of the data packets of the original multimedia data stream prior to the splitting step or flows obtained after the splitting step of this original stream and may be sent to the receiver, on a single physical path or in the same manner as the data packets of the multimedia data stream, i.e. on a plurality of physical paths, possibly separate from those used by the multimedia data stream fragments.
• the method according to the invention comprises a counter-reaction, from the receiver to the transmitter, for regulating the transmission of multimedia data packets, said counter-reaction being carried out by sending from the receiver to the transmitter of at least one indicator relating to the transmission of the packets on at least one physical path.
• the counter-reaction can be performed on at least one physical path.
• the method according to the invention may comprise a measurement of at least one transmission quality indicator on at least one physical link path based on information relating to either the transmission or the multimedia data transmitted on said transmission path. way, to both.
• the measured indicators may include the following indicators:
• These indicators can be calculated by conventional methods. These indicators can advantageously be calculated according to information concerning the transmission of flows on each physical path.
• the calculated indicators can be transmitted by the receiver to the transmitter in accordance with the TCP / IP protocol, through an Internet-type IP communication network, identical or not to the network used for the transmission of the multimedia data stream.
• the feedback can cause an adjustment of a data transmission rate on at least one path according to at least one indicator relating to the transmission. It can also, for example, cause a variation of a global encoding rate on at least one internal or external encoder if this is possible.
• the indicators may be received by a receiving module at the transmitter and transmitted to one or more control modules, such as a split control module, an encoding rate control module, an encoder signal transmission control module on at least one path, etc. to be used in the readjustment of the flow of the operations performed by these modules.
• a system for transmitting a multimedia data stream from at least one transmitter to at least one receiver through at least one link comprising at least one communication network using the IP protocol comprising: means for packetizing, on transmission, at least part of the data of the data stream in accordance with a predefined format;
• the architecture chosen may advantageously be a microprocessor and bus architecture, for both the transmitter and the receiver.
• This architecture allows a great modularity in terms of input and output and can accommodate any form of input and output interfaces adapted to this bus.
• a PCI 32 or PCI 64 technology bus (which also includes Compact PCI and PMC) can typically be used.
• PCI 32 or PCI 64 technology bus (which also includes Compact PCI and PMC) can typically be used.
• the system according to the invention may comprise means of counter-reaction from the receiver to the transmitter making it possible to regulate the transmission of the packets of multimedia data, said counter-reaction being effected by sending said receiver to said transmitter of least one indicator for transmission.
• the system may comprise means for correcting at least one transmission error of multimedia data packets received by means of redundancy data.
• These means may further comprise redundant data packet formation means for data correction.
• the system can include data storage means such as a memory or means for performing Queue and synchronization functions of the different elements of the system.
• FIG. 1 represents a general diagram of use of the system according to the invention
• FIG. 2 is a diagram of an example of splitting and reassembly of the multimedia data stream according to the method according to the invention
• FIG. 3 is a diagram of an example of splitting and reassembly of the multimedia data stream taking into account the transmission quality in accordance with the method according to the invention
• FIG. 5 represents a hardware architecture of a transmitter according to the invention
• FIG. 6 represents a hardware architecture of a receiver according to the invention
• FIG. 7 is a diagram of an input electrical adaptation module according to the invention.
• FIG. 8 a diagram of a general architecture of a transmitter according to the invention.
• FIG. 9 is a diagram of an electrical output adaptation module according to the invention.
• FIG. 10 is a diagram of a general architecture of a receiver according to the invention; and the general diagram of a use of a system according to the invention is presented in FIG. 1.
• the system is composed inter alia of an emitter and a receiver which are composed respectively of two devices IPSplit 11 and IPCombine 12
• the multimedia data stream F to be transported is composed in this example of a digital video and audio source and can be delivered in different formats and interfaces: - MPEG2 Transport Stream on ASI,
• IPSplit 11 encapsulates or re-encapsulates this data and distributes fragments of the multimedia data stream over multiple access links using multiple access devices 13 and network paths to provide the throughput and redundancy required.
• Access to the network 14 can be done in many ways, the main thing being that it is an IP network. We can mention as means of access:
• the fragments of the original multimedia data stream F are conveyed in the network 14 by several paths.
• IPCombine 12 connected to the network 14 by means of a plurality of connection equipment 15, reassembles the original multimedia data stream F from these stream fragments.
• the original multimedia data flow is delivered to the client according to different formats and interfaces:
• the diagram in FIG. 2 generally illustrates what IPSplit 11 and IPCombine 12 provide as a traffic distribution function over several paths 21.
• the packets 22 corresponding to the original F stream carry a sequence identifier to guarantee their order. If this is not the case, they will be encapsulated in a packet, typically RTP, to add this order information.
• the bit rate of this input stream is D.
• the IPSplit 11 splits the original data stream to the different paths 21, in taking account of the flow constraints of each of the paths 21.
• Each path 21 conveys a flow Di for the path i.
• the sum of the bit rates of the paths 21 is greater than or equal to the bit rate D of the original stream F.
• the IPCombine 12 collects the portions of the original multimedia data stream F that are conveyed on each path 21 and the original multimedia data stream F is outputted.
• the diagram in Figure 3 illustrates an improvement of the previous process.
• the transport protocols used make it possible to obtain measurements 32 of the quality of the transport channels used by the flow fragments.
• jitter, packet loss rate and reordering can be measured.
• a feedback loop 31 allows the transmitter to adjust the bit rate allocated to each path 21 dynamically, depending on the quality observed on each path 21.
• Constraints The minimum / maximum rate of flow can be allocated by the user on each path 21 to enable him to force a control processor 33 to respect the constraints of the underlying network topology.
• Packets 22 are sent on each path 21 with an initial distribution set by the user.
• the control processor 33 applies a user-configurable strategy. It can for example decide, by a steering 35 to reallocate the flow differently: decrease that of the path n in this case and increase that of the other paths 21; it can also drive the internal or external encoder 36 (if necessary) to vary the encoding bit rate by a command 37 of the source encoder bit rate.
• control processor 33 may progressively attempt to restore the values initially requested by the user (distribution between the paths and the flow rate of the encoder 36) or not.
• This mechanism also makes it possible to manage the redundancy of lines 21. For example, it is possible initially to allocate all the flow on a line 21 with another line 21 without initial flow serving as a backup. In this case, in the event of a disturbance on the first line 21, it is possible to implement a strategy to switch the entire bit rate on the second line 21. Another strategy may be to decide to transmit on two lines 21 and to affect the bit rate on one or the other to lighten the one that would come in default.
• the following table illustrates some possible security cases (non-exhaustive). Note that to simplify this illustration, it does not take into account the increase in low bit rate ("overhead”) related to the encapsulation of the multimedia data stream during fragmentation.
• the solution also makes it possible to adapt to cases of redundancies less sliced than previously. Indeed, if for example a line 21 has significant errors or if its rate becomes partially unavailable, the solution will switch part of the flow on another line 21, until the conditions become correct on the line 21 impacted.
• the proposed FEC mechanism is in line with the recommendation of the Pro-MPEG Forum (Code of Practice 3 or COP3).
• Figure 4 provides an overview of the general mechanism of FEC.
• IPSplit calculates a new FEC packet FO, Fl, F3 based on the packets 22 of the original multimedia data stream F a redundancy information which is represented by FEC packets.
• Each FEC packet is calculated based on a number of original packets 22 identified.
• the FEC packets are then sent over the network 14 via one or more paths 21.
• the FEC data stream may follow, or not, the same partitioning strategy as the original multimedia data stream F.
• the bit rates on the paths 21 are increased a value Dfi which corresponds to the data flow rate FEC conveyed on the path i. This rate depends, among other things, on the reconstruction power of the selected FEC.
• the FEC data stream may be wholly or partly conveyed on at least one other physical path than those taken by the multimedia data stream.
• IPCombine 12 Uses FO Bundle Information
• the chosen architecture is a microprocessor and bus architecture, both for the transmitter and for the receiver.
• This architecture allows a great modularity in terms of input and output and can accommodate any form of input and output interfaces adapted to this bus.
• a PCI 32 or PCI 64 technology bus (which also includes Compact PCI and PMC) will typically be used.
• Figure 5 shows the typical architecture 50 of the transmitter.
• the input cards are modular and it is possible to put one or more cards of each type, depending on the interfaces 51 needed: - ASI acquisition interface with coaxial connectors
• the microprocessor 52 and the memory 53 are used for the processing of the different data streams.
• a co-processor 54 may be used to unload the processor 52 of certain jobs.
• the signals are received by the input interfaces 51, are processed by them in the case of the encoder, and are sent on the bus 55 in digital form to the memory 53 and / or the processor 52.
• the processor 52 retrieves these data and processes them, possibly with the aid of the co-processor 54. The processes in question are detailed in the remainder of the document.
• the processor 52 then sends the data to the output interfaces 56.
• These output interfaces can be composed of all types of network interfaces, for example, a Fast or Giga Ethernet interface with RJ45 or fiber optic connections.
• FIG 6 shows the typical architecture 60 of the receiver. We find the same architecture as for the transmitter, with the difference that the input cards are here generation cards.
• FIG 8 shows the details of the implementation of the transmitter. The entire chain is described here, but only the parts which are the subject of the present invention are presented in detail. The other parts are state of the art.
• Figure 7 shows a module 70 for electrical input adaptation.
• the multimedia stream F is received in electrical form.
• Several interfaces 73 are possible (mainly ASI, SDI, Ethernet). These interfaces 73 may be followed by an input protocol processing module 77.
• the input electrical adaptation module 70 makes it possible to encapsulate, using an RTP encapsulation module 74, the data composing the stream F received in the RTP packets 22. This is done for the Transport Streams, as for the SDI flow according to the recommendations of:
• RFC RTP A Transport Protocol for Real-Time Applications
• RFC 2250 A Transport Protocol for Real-Time Applications
• RTP Payload Format for MPEG1 / MPEG2 Video RTP Payload Format for MPEG1 / MPEG2 Video
• the module 70 may comprise a clock 74 and a FIFO 76.
• the module 70 can also perform the compression of uncompressed video and audio signals.
• an additional compression module generates an MPEG2-TS stream and is therefore in the same case as an external TS stream.
• packets may be received either as UDP packets containing TS packets directly or as RTP packet streams containing TS packets. In the latter case, the input module will only be satisfied to ensure the insertion order of the packets in the input FIFO.
• the adaptation module generates RTP 22 time stamped and ordered packets. These packets are placed in the EIQ input FIFO in their natural order "Ascending and Continuous Number Sequence".
• the packets are extracted from the EIQ input queue based on the fill rate of the EIQ input queue. This rate will be adjustable to absorb more or less input jitter. As soon as the fill level exceeds the set rate, the Weighted Round Robin (WRR) 81 will begin extracting packets 22 from the EIQ input queue for processing.
• WRR Weighted Round Robin
• the objective is to distribute the stream fragments to different paths 21 while respecting initial distribution constraints. This is the step I of splitting the stream to several paths 21.
• each path i carries a part of initial flow rate denoted by T (i) the fraction of the total flow rate that one wishes to be absorbed by the path].
• T (i) bitrate of the original multimedia data stream fragment to be routed on the chemini / global bitrate of this stream.
• Tmin (i) is the minimum transportable fraction on the chemini.
• Tmax (i) is the maximum transportable fraction on the chemini
• the scheduler 81 uses T (i) as the weight to affect the packets extracted from the input queue EIQ in each of the output queues EOQi, typically composed by FIFOs, each corresponding to a path 21. This is done in accordance with the operation of a Round Robin scheduler.
• the RTP packet Before being inserted into the output queue EOQi on the specified path 21, the RTP packet is re-encapsulated in a new RTP packet specific to each path 21, by modules 83, called "SH-Insert modules". This is step II in the reference scheme. At the end of this step, the original packets are encapsulated in a new RTP packet called RTP-SH detailed below.
• the packets are sent over the network thanks to the module 82, during a step III, called "Dequeuing and flow control step".
• the module extracts the packets from the output queue EOQi for path i.
• a simple version of the module 82 will simply extract the packets according to the filling rate of the associated queue EOQi. In this case, it is the very operation of the scheduler WRR 81 which ensures the distribution of the flow on each path.
• the module 82 can provide smoothing and flow control. In this case, the implementation is based on a traditional "token bucket filter" strategy.
• the module 82 extracts the RTP-SH packets from the output queues (EOQi) to send them on the IP network 14 to the address and on the UDP port corresponding to each path 21.
• This sends RTP-SH packets is made through a UDP / IP communication layer, comprising UDP protocol processing and IP protocol processing respectively by modules 85 and 86, typically on Ethernet support.
• UDP protocol processing and IP protocol processing respectively by modules 85 and 86, typically on Ethernet support.
• Ethernet interfaces 87 may be used.
• FIG 10 shows the details of the implementation of the stream receiver / re-assembler.
• the flows 102 of RTP-SH packets of each path 21 are received on one or more interfaces 101, of the Ethernet type, for example.
• Each of the paths 21 ends on a couple (IP address, UDP port) distinct. This is what makes it possible to differentiate the different paths 21 at the reception.
• the reception of streams 102 is performed by a module 104 for processing the IP protocol and a module 105 for processing the UDP protocol. This is the processing step V, involving the UDP / IP layers and the network physical interfaces.
• the packets are delivered to the next RTP 103 processing module, during a step VI of reading and processing of the RTP protocol.
• Packets in RTP-SH format are received on each path 21. After the conventional operations of processing the IP 104 and UDP 105 protocols, two operations are performed on these packets: • The order of the packets is taken into account and the RTP packets are inserted neatly on the basis of the "Sequence Number" in the RIQi input queue. Packets are ordered in this queue. To do this, the RTP protocol processing module 103 inserts the packet in the RIQi queue at the right place so that the order of the SNs is respected (strictly increasing from the head to the tail of the queue). The processing module 103 also ensures the deletion of the duplicate packets.
• the queue RIQi is not a FIFO but a queue allowing the manipulation of the position of the packets.
• the module 103 of each path computes in particular:
• the RFC RTP specifies how to calculate these quality indicators, especially jitter.
• the number of received packets makes it possible to deduce an average throughput over a short period and over a long period.
• the "timestamps" received in the RTP packets are used to synthesize a local clock 96, image of the remote clock 75.
• the packets of each path 21 are present in separate queues. RIQi, arranged in an orderly fashion according to the SN (descending from the tail to the head of the queue).
• Step VII comprises reassembling the source multimedia data stream F from the stream fractions 102.
• the reassembly process retrieves the packets from each queue RIQi, corresponding to each path (i), to reconstruct the packet. original multimedia data stream.
• the next extracted packet is elected based on the smaller SN (SNIn).
• the following logic is used by the scheduler 107 to reassemble the packets optimally by respecting two constraints:
• a minimum threshold of "dequeuing" is respected for each queue (Thr (i) for the queue RIQi).
• This threshold corresponds to a number of packets and also corresponds to the maximum disordination that a packet may undergo (a packet displaced from more than Thr (i) packets on a path 21 will not be reordered by the system).
• - allow the absorption of the latency difference introduced by the different transport paths. This makes it possible to re-phase streams 102 from different paths 21 to allow reassembly of the original multimedia data stream without reordering in the output queue (ROQ). So, if the maximum reordering has not been exceeded
• the packets 22 coming out of the reordering module 107 are the packets 22 of the original multimedia data stream F, arranged in ROQ according to their SNin.
• the logic is the following at each iteration (periodic): W
• a filling rate information 1071 and a minimum SN for each queue RIQi is communicated to the scheduler 107.
• the insertion in ROQ is done in the same way as the insertion into
• RIQi that is to say, by ensuring the good order of the package, according to SNin.
• the choice of the value of Thr (i) is made in such a way as to avoid artificial latency in the RIQi queues.
• a value of Thr (i) proportional to the bit rate of the original multimedia data stream fragment carried on the path 21 of order i makes it possible to avoid introducing an artificial latency.
• the algorithm allows the RIQi of the paths 21 having the weakest latencies to play the role of "delay line" by buffering the flow adaptively.
• RIQi must be sized to absorb the maximum latency difference between paths.
• each RIQi should have a size to absorb the difference in maximum latency between paths. This size is proportional to the product of the maximum throughput of the original media data stream and the maximum difference in latency allowed between paths 21.
• the packet elected by the previous method is inserted into the output queue (ROQ) after the RTP-SH was extracted from this packet, during a step VIII extraction of the splitting header and re-sequencing performed by a module 108, called "SH-Extract & Seq".
• the insertion into the output queue (ROQ) is accompanied by a possible reordering according to the SN of the original multimedia data stream.
• the packets 21 are extracted from the output queue by a module 109 for jitter suppression and flow control.
• the emptying of the packets of the queue ROQ and their transmission to the module 90 of physical adaptation and protocol is assured the module 109 whose operation is activated when the rate of replacement of ROQ, represented by 1093 exceeds a fixed threshold during the configuration.
• the implementation of this module 109 is done on the basis of the standard methods of jitter suppression and flow control. It relies, among other things, on the TS ("Timestamps") of the data streams received and on the data 1092 transmitted from clock 96 synthesized locally, by a module 961. It controls, by a control 1091, the output rate of the stage of a module 90 for physical adaptation and protocol for the output of the packets and it is he who extracts the packets from the output queue (ROQ).
• the receiver's physical and protocol output adaptation module 90 is described in FIG. 9.
• the payload of the RTP packets received by this module is de-encapsulated by a RTP decapsulation module 92 and their protocol is adapted to the output medium.
• the raw data thus obtained is stored in a queue.
• the module 90 then provides, by an output protocol processing module 93, the formatting of these raw data to the interface specific output protocol 94 selected.
• the reformatting step may be deleted. The data thus reformatted is sent to the electrical output stage 95.
• the output rate is set. This rate is set by the upstream rate and jitter control module 109 by the command 1091.
• quality indicators 1002 are calculated by the module 1001 for calculating the reception quality indicators, on the basis of the information 1000 transmitted by the module 103 for processing the RTP protocol.
• This information 1000 includes path reception statistics, i.e., jitter, packet loss, de-sequencing, receive queue size, and the like.
• the module 103 calculates, by conventional methods and for a series of time periods (short, medium, long), the following indicators: the number of packets received and bitrate,
• the number of desynchronization of the received stream This data is possibly correlated with the value of TS and SN that are transported in the RTP stream.
• the calculated indicators 1002 are transmitted by the reception statistics sending module 1003, followed by a network adapter 1004, to the transmitter in TCP / IP messages via an IP network, identical or not to the network. used to transmit audiovisual data streams.
• the data is transmitted periodically, at the initiative of the receiver. The latter transmits at a regular frequency which can be parameterized by the user but can also transmit more frequently according to the measured values.
• the network adaptation is the physical adaptation to the communication network This is for example an Ethernet type adaptation.
• the emitter of the multimedia data stream receives the quality indicators 1002 sent in the previous step.
• a network adaptation is performed beforehand to adapt to the physical support of the IP network.
• the data is received in the form of TCP / IP packets, formatted with the previous application protocol.
• the reception module 891 decodes the quality indicators 1002 according to the application protocol and transmits them to the control module 89 for fractionation and encoding rate.
• the instantaneous rates are calculated by the module 82. This is a simple rate calculation based on the reference clock 75 and on the number of packets passed over a given period. Conventional instantaneous flow estimation methods in this type of context will be used.
• control module 89 fractionation and encoding rate that the decision intelligence to change the rate allocation and change the encoding rate to adapt to the operating conditions of the network.
• This module 89 makes it possible to control the encoding bit rate of the adaptation module 88, by a control 895, the scheduler 81 by a control 896, the FIFOs EOQi by a control 897, the modules 82 by a control 898. receives for these checks, 893 fill rate information FIFO output EOQi and 892 instantaneous flow information modules 82.
• the adaptation module 88 for the control of the encoder enables control 881 of the physical and protocol input adaptation module 70 and in particular of the encoder if the module 70 contains one, and if appropriate a control 882 of an external encoder through an RS232, RS422 or Ethernet interface.
• the standard RTP header has the following form:
• Payload of the new package. It is therefore between the standard RTP header and the "payload” of the original packet.
• the insertion of the "Splitting Header” for this type of packets is carried out in a manner identical to that previously presented.
• the "Splitting Header” is a "header” specific to the "payload” in the sense of RFC RTP. It is therefore transparent at the RTP level since it is included in the RTP payload.
• the proposed "Splitting Header” is defined to allow transportation of Transport Timestamp (TS) information.
• TS Transport Timestamp
• RTP of the TS is homogeneous with the notion of "presentation timestamp” defined in MPEG2 for example. It is the sampling time of the data and not the moment of their transmission (and therefore of the rate of transmission). It may be necessary, in order to have fine control of the transport jitter and the reconstitution of the reference clock, to have to insert a transport TS inserted at the time of sending on the network.
• the proposed "Splitting Header” transports the previous information and transports the original TS, the "Transport Timestamp" being transported in the RTP header.
• the RTP-SH is therefore in the following form:
• I V 2 I Orig PT
• V is the version of the "splitting header". The version presented is version 2.
• Oil PT is the value of "Payload Type" in the original stream.
• the data inside the dashed box is optional, depending on the values of X and CC.
• the content of the RTP header is changed when passing in the transmitter at the SH level and in the receiver. The changes are made as follows:
• the transmitter substitutes the PT (Payload Type), SN (Sequential Number) and TS (TimeStamp) values of the original packet with fragmented stream-specific values.
• PT Payment Type
• SN Sequential Number
• TS TimeStamp
• the transmitter inserts the "Splitting Header" into the "payload” header of the original packet.
• the original values of "PTin” and “SNin” are copied in the "Splitting Header".
• the packets of the fragmented streams have the following form:
• the payload of this new RTP packet consists of the
• PTSplit is inserted by the transmitter to match RTP requirements. These values will be used to characterize the quality of the link corresponding to the path that these packets will take. "PTin”, “SNin” and “TSin” are the copies of the "header” values of the original RTP stream, they will be used to reconstruct the destination stream.
• the invention is not limited to the application to the example described above and is applicable to the transmission of any multimedia data stream.

Applications Claiming Priority (2)

Publications (1)

Family

ID=36169152

Family Applications (1)

Country Status (4)

Families Citing this family (14)

Family Cites Families (7)

• 2005
  • 2005-12-16 FR FR0512786A patent/FR2895181B1/fr not_active Expired - Fee Related
• 2006
  • 2006-12-15 WO PCT/FR2006/002755 patent/WO2007080284A2/fr active Application Filing
  • 2006-12-15 US US12/097,541 patent/US20080267216A1/en not_active Abandoned
  • 2006-12-15 EP EP06841958A patent/EP1961165A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events