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/60—Network streaming of media packets
  • H04L65/70—Media network packetisation
• • 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/38—Flow control; Congestion control by adapting coding or compression rate
• • 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/24—Negotiation of communication capabilities

Definitions

• the present invention relates to the field of telecommunications and more particularly to the field of packet communication networks.
• this type of network it is possible to route data flows associated with real-time services.
• IP Internet Protocol
• IETF Internet Engineering Task Force
• the invention relates more particularly to a coding / decoding rate adaptation of real-time signals such as voice or video signals during a real-time communication session between two communication terminals.
• This rate adaptation and related mechanisms are suitable for transmitting digital signals such as audio signals (speech, music or others), however they apply to other real-time signals such as video.
• FIG. 1 An example of an existing voice over IP communication system is described with reference to FIG. 1.
• This figure describes a bidirectional voice over IP (VoIP) communication system with two telephony terminals (100 and 150) connected by a packet network. IP type (125).
• VoIP voice over IP
• IP type 125
• the "signaling plan" is not represented in this figure, but the possible solutions for establishing and managing calls can be based on various known protocols, for example:
• SIP / SDP for "Session Initiation Protocol / Session Description Protocol"
• IMS for "IP Multimedia SubSystem”
• JSEP for "JavaScript Session Establishment Protocol" that uses the SDP syntax to define WebRTC session descriptions (with a WebSocket exchange or other means).
• Figure 1 is a simplified view of the "media plan" and the audio system used when the call is established between 2 terminals (100 and 150) connected by an IP network (125).
• the ambient acoustic signal is for example picked up by a microphone (101 and 151) on each side of the communication.
• the case of a mono input / output signal can easily be generalized to a multichannel case where several microphones and / or speakers are used. Similarly, the microphones and speakers can be replaced by cameras and screens in the case of video signals.
• the remote signal is played back on a loudspeaker (102 and 152).
• the audio signals picked up and restored generally undergo different pre / post processing in transmission and reception (103 and 153), for example:
• the transmit preprocessed audio signal is encoded in successive frames - typically with a frame length of 20 ms - this length is typically between 10 to 60 ms for conversational applications.
• Coded frames are packaged as IP packets (104 and 154).
• the packets are typically transported by the RTP protocol (for "Real Time Protocol” in English), described in the IETF RFC 3550 specification, this protocol is located above the IP / UDP (for "User Datagram Protocol") transport protocols. English).
• the UDP protocol may be replaced by another transport protocol, for example by TCP (for "Transmission Control Protocol” in English), in particular to facilitate the crossing of networks with NAT network address translation (for "Network Address Translation”). "In English), proxies or firewalls.
• reception (105 and 155) the packets are received in a jitter buffer to compensate for variations in the reception times, and the signal is decoded (compensating for any losses of frames), finally the reconstructed signal is post-processed. (103 and 153) and returned.
• RTCP Real-Time Control Protocol
• RTCP allows transmission of control packets in separate packets of the RTP stream. It is recalled that the RTCP packets may have a substantial size and therefore result in a significant additional bit rate; moreover, the possible loss of packets can be problematic, because if RTCP is used for adaptation purposes, the transported feedback may be lost.
• the sending of packets by the RTCP protocol can be discontinuous and non-repetitive, which can make the adaptation less reactive and dependent on network conditions (transmission delay, packet loss, etc.).
• the application must support and use the RTP AVPF profile (for "Audio Video Profile with Feedback") so that RTCP is really usable for media adaptation.
• the voice-type applications on IMS currently allow only the AVP profile (for "Audio Video Profile") which restricts the use of RTCP; media adaptation in the terminals - if used - can rely on the monitoring of network conditions, including the information in the RTCP RR reports (Receiver Report) on packet loss or jitter being sent on average every 5 seconds.
• the transmitter in order for the transmitter to make an optimal end-to-end adaptation decision, the latter must receive a feedback from the remote receiver indicating the perceived quality at the end. for example, indicators such as the observed loss rate or the available bandwidth estimated by the remote receiver.
• the adaptation decision is made by the remote receiver (155) and transmitted by "feedback" to the local transmitter (104) (for example the choice of mode or bit rate to use) - this feedback is transmitted through the remote transmitter (154) and the local receiver (105).
• FIG. 1 indicates this feedback by dotted arrows for the direction going from the receiver 155 to the transmitter 104.
• this feedback can be done in the other direction of the communication, with a feedback from the receiver 105 to the receiver.
• transmitter 154 through blocks 104 and 155; this opposite direction is not represented on the figurel so as not to weigh down this figure.
• an adaptation solution for modifying the effective bit rate on the network consists in varying the number of consecutive frames of signal in a packet ("frame bundling" in English) and thus varying the packet rate ("packet rate” in English) and the relative bit rate of IP / UDP / RTP protocol headers (and lower layers).
• FIG 2 describes an advanced example of rate control of a multi-rate codec called iSAC (for "Internet Speech Audio Coded").
• the iSAC codec is a proprietary code developed by GIPS (Global IP Solutions). Since 2011, iSAC source code is available in Google Chromium TM open source project WebRTC.
• the codec operates in two different modes:
• Wide Band (WB) mode encodes an audio band of 0 to 8kHz with a frame length of 30 or 60 ms.
• SWB mode encodes an audio band of 0 to 12kHz or 0 to 16kHz with a frame length of 30ms.
• the rate of the iSAC code is variable; the average bitrate can range from 10 to 32kbit / s in Wide Band mode and from 10 to 56kbit / s in SuperWideBand.
• the iSAC codec can operate in two modes of transmission on the channel:
• “Channel Adaptive” mode takes into account bandwidth estimates made by the iSAC decoder and allows the coding rate to be adjusted, while the “Channel Independent” mode simply follows a target bitrate ("target bitrate”). ").
• target bitrate target bitrate
• the audio processing blocks 103 and 153 and the network 125 are deliberately omitted in FIG. 2 in order to lighten the figure. We find the capturing elements and audio reproduction (blocks 101, 102 and 151, 152).
• the coding rate (blocks 201, 251) is adapted in the iSAC code (blocks 202, 252) from the downstream rate indication, estimated at the receiver (blocks 205, 255).
• the receiver (blocks 205, 255) estimates the bandwidth available downlink at each reception of packets from the following information:
• the estimated bit rate is then made available to the transmitter via a shared structure (blocks 207 and 257).
• the transmitter (blocks 204, 254) sends a field called BEI (for "Bandwidth Estimate Index" in English) whose values range from 0 to 23 to indicate the available bandwidth estimated by the receiver; the BEI field indicates a value of available bandwidth ("bottleneck") estimated among values defined between the minimum and maximum target rates of the iSAC codec (from 0 to 11 in WB mode and from 0 to 23 in SWB mode).
• BEI for "Bandwidth Estimate Index" in English
• the BEI field is decoded at the other end of the chain (blocks 203, 253).
• the bandwidth estimate in the iSAC codec is also accompanied by an estimate of the jitter not described here but used to estimate the size of the stuffing described below; the estimated jitter is represented on 1 bit to indicate a low or high value and it is transmitted in the BEI field in WB mode (0 if the BEI is between 0 and 11 and 1 if it is between 12 and 23) or coded in the bit stream (payload of the current frame) in SWB mode.
• the rate adaptation is implemented on the transmitter side.
• the coding performed at 201 has a rate updated by the block 202 from an BEI field decoded at 203.
• This decoded field has been encoded at 254 from an available bandwidth estimate made by the block 255 of FIG. receiver 155.
• the transmission in the other direction is carried out in the same way with the corresponding blocks.
• a method of padding in random bits at the end of the packet is performed to test whether it is possible to increase the bandwidth probing rate.
• This simple method makes it possible to artificially increase the size of some packets on transmission (210 or 260 respectively) in order to be able to estimate at the end of the reception chain (205 or 255 respectively) whether the available bandwidth on the channel of Transmission allows the use of a rate higher than the current rate.
• this method uses random bits with no other use than the bandwidth test.
• the size and the decision to send the bit stuffing are determined using a rate model ("rate model").
• rate model typically the first 10 seconds
• the rate is maintained at a minimum rate.
• three consecutive packets with stuffing bits are sent to test the channel, with a maximum interval of typically 500 ms.
• the size of these consecutive packets is set so that the instantaneous rate associated with packet i is given by (1 + g)
• R ir is the estimated bandwidth estimated at packet i and the adaptive term (greater than> 0) is calculated heuristically.
• the principle is to send regular rate peaks ("bursts") on the channel to test a rate increase over the current rate.
• the rate model implemented in blocks 210 and 260 is based on a bottleneck model limiting the bandwidth available in the network.
• This rate model relies on several internal states defined to the receiver, including a binary overuse detection of the bandwidth by the last packet received with a measurement of the time elapsed since the last detected bandwidth exceeded. (in ms), as well as information on the queue modeling the "bottleneck" (number of packets that remain to be transmitted, increase the delay).
• the rate estimation performed at the receiver is generally effective in decreasing the coding rate, that is, detecting that the available bandwidth is lower than the current rate and that the rate must be lowered.
• the method of random bit stuffing to check that the current bit rate can be increased is not optimal, because it introduces random unused and uncontrolled bits.
• the iSAC codec produces an average bit rate that can be adjusted quite finely between a minimum bit rate and a maximum bit rate (eg 10 to 32 kbit / s or 10 to 56 kbit / s), whereas a multi coded flow rate operating according to a defined set of discrete rates, such as an AMR, AMR-WB or EVS coding, does not operate over a continuous range of rates.
• the iSAC codec rate adaptation method using a receive rate estimate and a bit-stuffing channel test, assumes the use of an iSAC-coded (BEI) -specific field.
• BEI iSAC-coded
• This specific field does not exist for other types of codecs, in particular for AMR, AMR-WB and EVS multi-rate codecs.
• the CMR field of the AMR, AMR-WB and EVS codecs is different from the BEI field of the iSAC codec, since the one (BEI) represents information on the estimated available bandwidth at the receiver and assumes a "transmitter-based" adaptation.
• CMR Code Division Multiple Access
• the issuer part is based on the loss-based rate. It transmits in the headers of the RTP packets absolute transmission times called "abs-send-time", which are used to estimate bandwidth available in the receiver part. It uses the reports RTCP REMB indicating the estimated bit rate A r and the observed frame loss f t by the remote receiver to adapt the coding rate: the target coding bit rate A s is respectively increased, maintained or decreased when the loss rate is negligible, low or high:
• the actual coding rate is obtained as min (A s , A r ), i.e., the minimum between this target coding rate and the last available bandwidth value estimated by the remote receiver (received by RTCP). .
• the receiving part is based on the variation of the unidirectional delay ("delay-based”). It uses a finite state machine with 3 states (decrease, hold, increase) and an estimate in reception of the available bandwidth by Kalman filtering.
• the bandwidth estimate is based on a modelization of the variation of the unidirectional delay ("one-way delay") defined as
• t s (i) and t r (i) are the transmission times (according to the "abs-send-time" information sent in the RTP header) and the reception of the packet i, in the form of two components :
• n (i) is the variation of the queue delay - estimated by Kalman filtering - and n (t) is the network jitter - considered as a noise.
• This adaptation method uses heuristics for adaptation and assumes that it is possible to fine-tune the rate with specific multiplicative factors (1.05 and h) for the rate increase. It is difficult to apply to voice codecs such as EVS which are multi-bitrate with a set of discrete bit rates. For example, the ratio between successive bit rates for the codec ranges from 1.11 to 1.5 for the EVS codec with fixed rates of 7.2 to 128 kbit / s. Moreover, the use of RTCP packets (of the REMB or other type) is not always possible in VoIP applications restricted to an RTP profile such as AVP (for Audio Video Profile, defined in IETF RFC 3551) which limits the interest of RTCP for adaptation purposes.
• AVP Audio Video Profile
• VoLTE Voice over LTE (Long Term Evolution) telephony applications in English designating a voice transport technique on the 4G LTE mobile networks specified in GSMA IR.92 and VoWifi (for "Voice over Wi-Fi") designating a voice transport technique over the Wi-Fi network specified in GSMA IR.65
• VoWifi for "Voice over Wi-Fi” designating a voice transport technique over the Wi-Fi network specified in GSMA IR.65
• coding adaptation mechanisms are described in chapter 10 of the 3GPP TS specification.
• the TS 26.114 specification contains recommendations (see clause 7.5.2.1.6) on the initial coding rate (ICM) for use at the beginning of a call to avoid link congestion. and it is recommended - if no flow control information has been received for a period of time - to gradually increase the encoding mode (bit rate) to at most the ICM value corresponding to the allowed coding rate ; if no poor quality is detected or in the absence of flow control information, it is recommended that the transmitter increase its flow in progressive stages with a waiting time of the order of 500-600 ms .
• This adaptation approach is very heuristic.
• the rate increase is based on the changeover to the next higher coding mode, with monitoring of the quality indicators or waiting for the receiver to receive a request (typically CMR or RTCP-APP) to validate the request. flow increase. This method is not optimal because it is based on incremental stepwise heuristics and causes sudden rate change jumps with "blind tests" of rate increase.
• the invention proposes a method for adapting a real-time signal coding rate of a real-time communication session between transmitter devices and communication terminal receiver devices, a transmitter device comprising an encoder multi-rates according to a set of discrete rates.
• the method is such that it comprises a step of increasing the encoding rate test to the transmitting device by the transmission of a current frame and at least one copy of a previous frame according to a chosen offset.
• redundant packets The fact of testing the bit rate increase by at least one copy of a previous frame, hereinafter called "redundant packets", makes it possible to increase the bit rate without sudden jumps since it is possible to define the transmission parameters in order to avoid blindly test the higher discrete flow and risk degradation of the quality without being able to compensate for the consequences of a direct increase of the flow rate. This test step makes it possible to check whether the available bandwidth is sufficient.
• the redundancy of the packets can be used to, for example, correct the losses of possible frames, if the increase in rate is not justified and if it creates a problem of congestion.
• the redundant packets then serve both to test the rate increase and also to correct frame losses.
• the test step is implemented as long as no rate adaptation request is received from a receiving device.
• the receiver device when it implements a bandwidth estimate, it can inform the transmitting device of a higher or lower rate change. In either case, the test stops to perform the requested rate change.
• test step is carried out after a lower discrete flow rate change.
• This process thus makes it possible to further modulate the increase in flow (less abrupt increase), but it can however introduce degradations in the transmitted signal.
• the test step is implemented when a timer has reached a threshold since the last adaptation request received from a receiving device.
• the timer for initiating the boost test is adapted based on available bandwidth information estimated to the receiving device.
• test step is carried out as a function of information on the evolution of the coding rate obtained.
• the information of evolution of the coding rate is obtained from an available bandwidth history estimated at the receiving device.
• the different bandwidth estimates available at the level of a receiver device make it possible to obtain a trend of evolution of this estimate and to deduce therefrom information on the evolution of the available bandwidth.
• test step is carried out after receiving an adaptation request received from a receiving device and comprising a redundant packet transmission request according to selected transmission parameters.
• the receiver device determines the relevance of the implementation of a test step according to bandwidth estimates made.
• the adaptation request is for example determined to the receiver device, depending on the estimated available bandwidth.
• the present invention also provides a method for determining a real-time signal coding rate adaptation request of a real-time communication session between transmitting devices and communication terminal receiving devices, a transmitting device comprising an multi-rate encoder according to a set of discrete rates.
• the method is such that it comprises a step of estimating an available bandwidth for a receiving device and of constructing an adaptation request to be transmitted to a transmitting device and comprising a request for implementation of a encoding rate increase test step of transmitting a current frame and at least one copy of a previous frame according to a chosen offset.
• the invention also relates to a device transmitting a communication terminal adapted to implement real-time communication sessions and comprising a multi-rate encoder according to a set of discrete rates.
• the transmitting device is such that it comprises a packet transmission unit able to implement a step of testing for increasing the coding rate by the transmission of a current frame and at least one copy of a frame preceding one according to a chosen offset.
• This device has the same advantages as the adaptation method described above, which it implements.
• the invention also relates to a receiver device of a communication terminal adapted to implement real-time communication sessions and comprising a multi-rate encoder according to a set of discrete rates.
• the device is such that it comprises an estimation module capable of estimating an available bandwidth and a module for constructing and transmitting an adaptation request, able to construct and transmit to a transmitting device, a request for setting implementation of a coding rate increase test step by transmitting a current frame and at least one copy of a previous frame according to a chosen offset.
• This device has the same advantages as the method for determining an adaptation request described above, which it implements.
• the invention also relates to a communication terminal comprising a transmitter device as described and / or a receiver device as described.
• the invention relates to a computer program comprising code instructions for implementing the steps of the adaptation method as described and / or steps of the method for determining a request as described, when these instructions are executed by a processor.
• the invention relates to a storage medium, readable by a processor, storing a computer program comprising instructions for executing the adaptation method as described and / or steps of the method for determining a request. as described.
• FIG. 1 illustrates a VoIP communication system known from the state of the art and previously described
• FIG. 2 illustrates a known rate adaptation method of the state of the art and used with the iSAC code previously described
• FIG. 3 illustrates an embodiment of a voice-over-IP communication system according to one embodiment of the invention
• FIGS. 4a to 4c illustrate, in the form of flow charts, the steps of a method of adapting a coding rate in a first embodiment of the invention
• FIGS. 5a and 5c illustrate, in the form of flowcharts, the steps of a method of adapting a coding rate in a second embodiment of the invention as well as the steps of a method for determining a rate adaptation request according to one embodiment of the invention;
• FIG. 6 illustrates a hardware example of a communication terminal incorporating a transmitting device and a receiving device, according to one embodiment of the invention.
• the communication is carried out between 2 terminals A and B.
• the EVS codec over a more restricted bit rate range, for example from 9.6 to 24.4 kbit / s, or consider also a possible change of audio band, with fixed rates of, for example, 7.2 ( NB + WB) at 24.4 (NB + WB + SWB) kbit / s using the maximum coded band at each rate.
• the rate of the coding to the transmitter is adapted according to the invention by using, in a privileged manner, an in-band signaling to indicate adaptation requests with a CMR field present in the payload of the packets for the EVS codec.
• This type of in-band signaling is robust - in the sense that it can be repeated in successive RTP packets if necessary - and does not depend on the constraints on packet sending times for RTCP.
• RTCP for example RTCP REMB
• adaptation request signaling is done in the band by CMR.
• CMR Packetization
• NO_REQ of the EVS codec indicates that the CMR does not contain a request, and therefore the CMR information can be ignored; this allows to send packets without request, even when the sending of the CMR is systematic.
• SDP silent descriptors
• the DTX mode will be activated for the EVS codec, which implies that the invention will be applied only in the active signal periods, since it is not relevant to modify the mode of discontinuous transmission of SID frames to maintain maximum DTX mode efficiency when enabled. It is recalled that for the AMR and AMR-WB codecs it is not possible to control the DTX mode at the SDP level, so that this DTX mode is always enabled by default.
• the use of application layer redundancy depends on the SDP parameter "max-red” .
• the "max-red” parameter gives the maximum duration (in ms) - at the transmitter - between the transmission of a frame (called primary) and the transmission of a redundant version; this parameter therefore makes it possible to set a maximum delay when redundancy is used.
• “max-red 20" indicates that it is possible to use redundancy and that a redundant frame can be transmitted up to 20 ms after the original frame.
• the CMR field - if present - is extracted (blocks 307 and 357) and the contents of this CMR field are written - except in the case of "NO-REQUEST" (NO_REQ) or if the CMR field is not present - in a structure called "CMR_Req" at 306 and 356, which is shared between the sender and the receiver in the same terminal.
• the CMR_Req structure will comprise several entries:
• blocks 307 and 357 are entitled "Ext.CMR_A / B" to cover the general case of an extended CMR request used in the second embodiment; in the first embodiment the CMR request will be a conventional request.
• these entries may be supplemented by other information such as “requested_bandwidth” to indicate the requested coded audio band (NB, WB, SWB, FB) in the CMR, and entries called for example “activate_ca_mode” / “ca_fec_mode “/” ca_offset “to control respectively the activation of the” channel-aware mode “and the parameters of channel-aware mode (" FEC mode "worth LO or HI and” offset "worth -1, 0, 2, 3, 5 , or 7).
• the sender and the receiver are executed in parallel (for example in different threads or "threads"); this shared structure is then necessary and access to this structure is typically in a critical section with the use of a mutex to manage access in parallel.
• the CMR field to be sent is constructed and coded by the coding modules of the CMR field 302 and 352.
• the CMR field received is extracted by the extraction modules 307 and 357.
• the CMR field can be, or according to a first embodiment of the invention, a conventional CMR field with codes defined for the codes such as AMR, AMR-WB or EVS, or according to a second embodiment of the invention, an extended CMR field as described later in the second embodiment of the invention. production. In this second embodiment, an extended CMR is used to indicate the activation of a redundant transmission.
• the use of the EVS code in Primary SWB mode is restricted to simplify the description.
• the coding and transmission parameters adapted according to the invention are in this case the coding rate and the use of 100% redundancy.
• more transmission parameters could be considered for the adaptation, for example the bandwidth (NB, WB, SWB or FB) in the case of the EVS codec - if the range of flow used for the adaptation allows also to change coded band -, the type of redundancy (for example partial redundancy, or redundancy at more than
• Redundancy is defined here as a repetition mode of coded frames at the application level, as described in chapter 10 of specification 26.114. More particularly, the use of 100% redundancy is considered, which implies that the current packet contains the payload of the current frame and the payload of a previous frame shifted by a predetermined offset. Thus, this type of redundancy amounts to (approximately) doubling the instantaneous transmission rate (assuming that the bit rate of the current frame and that of the redundant frame are identical) by the copying of a previous packet in a punctual manner, in a of realization.
• the transmission parameters are provided by the block 305, 355 to the encoder / transmitter (block 301, 351) which applies these parameters during the coding and the transmission of data. the next coded frame (or next coded frames) until a new CMR request is received.
• this initial coding rate is set at the lowest rate allowed in the session, assuming no quality of service (QoS) guarantees.
• this initial flow rate may be defined as the maximum authorized flow (if information on a guarantee of flow "GBR" is available) or a predetermined intermediate flow between the minimum flow and the maximum flow.
• a bandwidth estimate is made (blocks 304 and 354).
• this estimate will be similar to the estimate made in the iSAC code from the information on the last packet received (keeping the history of the analysis made from the previous packets):
• This estimate of available bandwidth is performed each time a new RTP packet is received by the receiver.
• a different estimate of the bandwidth estimate to the receiver may be used, for example the estimation of the GCC congestion control algorithm, or other methods of estimating bandwidth available from the same information about receiving packets or derived information such as estimated loss rate or estimated jitter.
• the history of the estimated bandwidth at the reception of the packets over a predetermined time, for example 500 ms, including the packet that has just been received, is stored in the block 304 and 354, and that a shared structure called "BWJnfo" at 303 and 353 is defined to be able to communicate to the transmitter that a new CMR is to be sent and the information associated with that CMR.
• the "BWJnfo" structure comprises the following entries:
• the structures "BWJnfo" and “CMR_Req” will also include a field called “burst_uplink” associated with an extended CMR request, as explained later in the second embodiment.
• the available bandwidth history estimated at 304, 354 it is possible to take into account not only the instantaneous value of the bandwidth (updated upon receipt of the last packet), but also its tendency on the time horizon defined by the history (here for example 500 ms).
• This slope (also called the steering coefficient) is for example analytically given in the form: ⁇ (** - x) (y * - ⁇ ) / ⁇ (x, - x) 2 where (3 ⁇ 4, y are the time of reception and the estimated bandwidth at the reception of the packet i, x and ⁇ are the means of the x t and y t over the time horizon considered, in variants it is possible to use robust variants of linear regression, with a regularization according to the standard L1 or L2 In variants we can also use a trend estimate derived from the estimate of available bandwidth (which is possible for example if a Kalman filtering is used as in the GCC algorithm).
• the extracted request is read and converted (blocks 305 and 355) into coding / transmission parameters, which are listed below:
• the size of the RTP payload is often slightly greater than the "net payload" associated with the coding rate.
• the "net payload" associated with the coding rate.
• An overhead can also be present in a transmission context, such as with WebRTC technology, where RTP header extensions are used, which adds additional bytes to RTP packets. For example for voice communication, 12 bytes can be added in the RTP header if the following configuration is used:
• a extmap: 1 urn: ietf: params: hp-rtp: ssrc-audio-level
• this extra bit rate is not taken into account (subtracted from the RTP packet size) in the bandwidth estimate available to the receiver, this amounts to testing a higher rate than the current coding mode.
• the bandwidth actually used for a given frame (without 100% redundancy) will be biased towards a higher coding rate value, because of the additional octets in the RTP header if the RTP headers are only taken into account. after bandwidth estimation.
• this bias will be eliminated by giving the available bandwidth estimate (block 304, 354) only the size of the payload without the RTP headers. In variants of the invention it will be provided not to eliminate this bias, and it will be assumed that the receiver will compensate for this bias before forming the CMR to be sent.
• a first embodiment is presented wherein the transmitter and the receiver act in a coordinated manner and where the decision to activate the redundancy is made by the transmitter from the CMR reception information and the current rate.
• the flow is used to check whether it corresponds to the maximum rate allowed in the session, in which case the redundancy is not activated.
• the transmitter decides to test the channel by sending packets with redundancy, after a certain delay before triggering a rate increase test.
• each packet resulting from this test contains redundancy.
• the redundancy will be sent intermittently to limit the peak of average flow caused by the channel test.
• the decision initiative on redundancy is the responsibility of the issuer.
• the "normal" logic of the CMR field for the AMR, AMR-WB, and EVS codecs is to indicate that a maximum rate indicated by the CMR should not be exceeded; according to the invention; the transmitter must therefore normally comply with this constraint, which is particularly important in the case of interoperability with circuit-mode mobile systems which may have a maximum coding rate (for example 12.65 kbit / s for AMR-WB) lower to that authorized in voice on LTE (for example 23,05 kbit / s).
• an SDP parameter "adapt” the logic of the CMR field may be modified to allow the transmitter to temporarily exceed the limit imposed by the last CMR received, in order to test an increase in bit rate (which by nature does not respect the maximum throughput constraint of the last CMR received). If a terminal implementing the invention communicates with another terminal not compatible with the SDP parameter "adapt", the invention can not be used because it assumes that the remote terminal sends CMR a rate corresponding to an estimated bandwidth reception , which would not be the case.
• a CMR is sent to change the rate.
• this approach is sufficient to reduce the bit rate because the state of the art bandwidth estimate generally works well enough to detect that the current bit rate should be lowered when it exceeds the channel capacity. . Indeed, during a beginning of congestion, the receiver will observe an increase in queue delay or loss rate. However, when the current rate is less than the available bandwidth, the bandwidth is generally underestimated if a rate increase test is not implemented.
• the transmitter sends packets containing redundancy according to the invention for testing the channel. If losses are caused by this increase in throughput, they may be offset by redundancy. Using the Redundancy allows the channel to be tested before actually increasing the throughput and compensating for the induced losses proactively.
• the following adaptation parameters are defined which define the characteristics of the redundancy packets or "bursts" according to a following example of values:
• L burst 100 (defined in number of frames);
• redundancy offset K burst (its value is fixed at a value> 0, for example at 2, during redundancy, and it is -1 when redundancy is deactivated), we will see later that the offset can also be take a value that will be a function of a redundancy sending frequency parameter;
• Tc MR • elapsed time ("ti mer") since the last received CMR: Tc MR reset to 0 at each CMR reception (with a given rate, other than NO_REQ);
• T b ur st (defined in number of frames) set at 250
• f burst (its value is adapted but re-initialized to 1.0);
• FIGS. 4a, 4b and 4c show an exemplary implementation of a rate adaptation method with redundancy according to the invention in the form of flowcharts, implemented in a bidirectional system.
• FIG. 4a shows the steps implemented by the receiver according to a first embodiment of the invention, on receiving a packet.
• the communication is bidirectional and the following steps can be applied in both terminals.
• the extracted CMR is indicated in the shared structure "CMR_req", in particular to indicate that a new CMR has been received if it is present and different from NO_REQ.
• the "updated” input of the CMR_Req structure is set to "true” when a CMR (other than NO_REQ) has been retrieved.
• FIG. 4b details the steps X implemented at the receiver after extracting the information on the current packet (402).
• An estimate of the bandwidth is made according to one of the previously described methods (in 411). Then a mapping between the estimated bandwidth and the EVS discrete rates is performed (at 412) to determine whether there is a need to change the current receive rate and whether it is possible to switch from one to another. discrete flow to another.
• this correspondence is implemented according to the pseudo-code given in Appendix 1 to obtain the bit rate D from the available bandwidth B.
• this correspondence can be modified by taking for example the discrete bit rate of the upper or lower EVS code closest to the estimated bandwidth.
• step 414 If the estimated rate is equivalent to the current rate (N in 413), no rate information (block 414) is written to the shared structure "BWJnfo" and the "updated” entry of this structure is set to " false". If the estimated bit rate is different from the current bit rate (O at 413), the information required in step 415 (the value of the "requested-bitrate” entry) is written in the shared structure "BWJnfo" so that the transmitter can encode the CMR with the next frame to send, also setting the value of the "updated” entry to "true". A conventional change of rate request at a corresponding discrete rate will then be constructed and coded as in the case of an EVS codec of the state of the art.
• FIG. 4c details the steps implemented at the transmitter (including the coder) of a coding rate adaptation method according to a first embodiment of the invention.
• step 422 is implemented.
• the transmitter checks whether a rate increase test is to be implemented. It is verified that the conditions for activating a test for increasing the coding rate are checked. More specifically, in the preferred embodiment, it is decided to test a rate increase at 422 if the following conditions are simultaneously fulfilled:
• N burst Lburst + Khurst with for example L burst 100.
• the transmitter checks whether a CMR should be carried in the packet associated with the current frame to be coded. If so, the CMR data in the "BW_Info" structure is retrieved for later coding of the CMR.
• the sender then creates the header of the current RTP payload, if the CMR and ToC fields are to be inserted into the current packet.
• the coding of the ToC field is described in Figure A.4 and Tables A.4 and A.5 of Annex A of TS 26.445.
• the ToC field will describe both the bit rate of the current frame, the redundant frame rate, and the redundancy offset K burst (using the number adequate ToC associated with NO_DATA). It is recalled that examples of redundant frame structure are given in chapter 10 of the 3GPP specification TS 26.114 and the construction of the ToC field follows the principles given in this specification for the AMR, AMR-WB and EVS codecs.
• the current frame is coded at 427 and added to the packet data.
• the redundant coded frame corresponding to the offset K burst (stored in a queue or other data structure) is also added to the data of the current packet to be transmitted at 428.
• the packet thus formed with the headers (if any) and coded data is transmitted (428) using the information relating to the size of the payload RTP and the number of coded frames since the reception of the last CMR is incremented by 1 ( CMR T ⁇ - T CMR + 1).
• the current coded frame is stored in a queue for possible future use as a redundant frame.
• a parameter b AS limiting the bit rate to 24.4 kbit / s (in transmission of a single frame of 20 ms).
• redundancy it will be possible to limit the use of redundancy in two ways:
• this variant implies that before applying redundancy, a decrease in the bit rate at a lower discrete rate must be potentially performed (for example to test whether one can go from 13.2 to 16.4 or from 16.4 to 24.4 kbit / s).
• a lower rate eg 9.6 kbit / s
• the current rate eg 13.2 or 16.4 kbit / s.
• it would not be possible to use 2x13.2 kbit / s because it would exceed the bit rate of 24.4 kbit / s and only the cases 2x9.6 kbit / s and 9.6 + 13.2 kbit / s will be allowed.
• the activation of the redundancy may only be allowed during active signal periods to minimize the impacts of the increase in bit rate.
• redundancy refers to the period with which a redundant packet is used - so a frequency of x means that a redundant frame is inserted every x packets.
• the redundancy is used for example every 2 or 3 packets which allows to obtain on average a relative increase of fractional flow, in order to test (on average) the transition to the flow discreet immediately superior and not doubled flow.
• the redundancy offset is set to the same value as the frequency parameter (freq) for redundancy to be exploited.
• This other parameter defining the redundancy can be determined in step 423 of FIG. 4c as a function of information of the current flow rate and the immediately higher flow rate. For example, if the rate range 9.6 to 24.4 kbit / s is usable in a session with the EVS codec in Super-Wideband mode, we can use: - from a rate of 9.6 kbit / s, the rate increase test can be done with a redundant frame coded at 9.6 kbit / s every 2 packets (to arrive at an average throughput on the channel of nearly 14.4 kbit / s) or every 3 packets (approximately 12.8 kbit / s)
• the rate increase test can be done with a redundant frame coded at 13.2 kbit / s every 3 packets (approx 17.6 kbit / s) or all 4 packets (approx.16.5 kbit / s)
• the rate increase test can be done with a redundant frame coded at 16.4 kbit / s every 2 packets (approx 24.6 kbit / s)
• the redundancy sending frequency is therefore adaptive, depending on the current rate. It is 2 or 3 at 9.6 kbit / s, 3 or 4 at 13.2 kbit / s, 2 at 16.4 kbit / s.
• the redundancy offset will preferably be defined as being equal to the redundant packet sending frequency to compensate for possible losses of the larger packets. In variants it will be possible to use another offset to repeat, for example, the frame immediately following the packet with redundancy.
• the frequency can be chosen as a function of the current discrete bit rate DO and the discrete bit rate DI immediately higher for a given codec, such as the integer value closest to 1 / (D1 / D0-1).
• a second embodiment is then presented in which the transmitter and the receiver still act in a coordinated manner, but this time the receiver sends an explicit request for 100% redundancy activation to test an increase in throughput.
• the existing CMR codes of EVS are used to send a request to a given coding rate, when or increase the throughput based on the estimated available bandwidth.
• an unconventional CMR called Extended CMR is required to send a redundancy enable request, since the existing CMR codes of the EVS codec only allow for bandwidth, audio band adaptation and control of a special mode of partial redundancy at 13.2 kbit / s (called channel-aware mode).
• channel-aware mode it is assumed that the SDP session includes an additional parameter called without loss of "adapt" generality to signal and authorize the use of such an extended CMR, and that both terminals are compatible with the SDP parameter "adapt”.
• CMR codes are used according to this embodiment. are free, left for future use ("for future use”) or reserved (“reserved”) and are not currently used in the EVS codec specifications.
• the offset is set to the same value as the freq so that redundancy can be exploited.
• another convention may be defined to set the offset value.
• CMR_Req contains a field called “burst_uplink” which is set to "1", “2” or “3". "when extended CMR codes according to Table 2 are used, otherwise its value is set to -1. Thus by combining the "requested_bitrate” entry and this "burst_uplink” entry it is possible to fully report the type of request to be sent or the request received.
• redundancy is intermittently preferred: rather than doubling (approximately) the coding rate, the redundancy is used adaptively by example every 1, 2 or 3 packets which allows to obtain on average a fractional flow increase, in order to test (on average) the passage to the discrete flow immediately higher and not doubled flow. More generally, the frequency can be chosen as a function of the current discrete flow rate D0 and the discrete flow DI immediately higher for a given coding, such as the integer value closest to 1 / (D1 / D0-1).
• a rate adaptation request is determined and encoded into a CMR code (block 302 and 352 of FIG. 3). This CMR request is added by the local transmitter in the next packet to be transmitted.
• NO_REQ indicates the maximum allowed rate.
• the decision NO_REQ will be replaced by a decision SET_RATE to indicate the current flow.
• EVS it will be possible in the same way to replace the decision NO_REQ by a decision SET_RATE to indicate the current flow.
• reserved CMR codes are used, which justifies the Extended CMR notation (Ext CMR) in blocks 307 and 357 of Figure 3.
• the extended CMR codes are used to indicate a request for adaptation to increase the coding rate, this request indicates to the remote transmitter to test a bit rate higher than this given bitrate in the request - in this case the transmitter will activate by transmission of redundant packets, a transmission at this given bit rate with redundancy 100%.
• the transmitter can execute the request resulting from the CMR as in the first embodiment of the invention, by verifying that the "updated" entry is “true” in the "CMR_Req” structure and by applying the adaptation parameters contained in "CMR_Req”; after retrieving the parameters, the value of "updated” is reset to "false”
• the transmitter will be left with sufficient flexibility to execute the redundancy enable request based on the signal being encoded
• the rate increase may result in congestion with packet loss or jitter increase, so it is important when the band available pass-through is not known and tested blind (to estimate the "bottleneck” in the downward direction) not to exceed this limit over the channel excessively, besides the impact of losses and jitter is different
• these impairments can be more easily tolerated.
• Figure 5a shows the first embodiment of the extraction steps performed at the receiver.
• two pieces of information are extracted at the receiver: Transmission information of the current packet making it possible to estimate the available bandwidth (in 502) according to one of the estimation methods previously described.
• the extraction of this information is followed by the steps X described with reference to FIG. 5b;
• steps X also include the option of sending an extended request to enable redundancy using the "burst_uplink" entry.
• FIG. 5b details the steps X implemented by the receiver device after extractions of the information on the current packet (502).
• an estimate of the bandwidth is made according to one of the previously described methods (in 511). Then a mapping between the estimated bandwidth and the EVS discrete rates is performed (at 512) as previously described to determine whether to change the current reception rate and whether it is possible to switch from one to another. discrete flow to another.
• the decision "SET_RATE" of rate change is made according to this new bit rate.
• a conventional rate change request at a corresponding discrete rate is set at step 514; the associated data is written in the shared structure "BWJnfo" so that the sender can then code the match request with the frame to be sent.
• test condition verification step is performed at 516.
• This verification step 516 verifies the bandwidth estimation history and thus measures a trend of variation of the estimated bandwidth. If this trend is positive (0 to 516), i.e., if the estimated bandwidth tends to increase, then a decision "USE_RED" can be made and step 517 is then implemented.
• the time from which this "NO-REQ” decision remains selected can be measured to decide whether or not a rate increase test should be enabled. If this time elapsed time is less than a threshold (for example 500 ms), then a decision "NO_REQ” is taken (N at 516). The "NO-REQ” mode was not long enough. In this case, one will typically send no request (no CMR) or a CMR indicating NO_REQ in 519 - in the latter the data associated with the CMR NO_REQ are written in the shared structure "BWJnfo".
• a threshold for example 500 ms
• NO_REQ decision will be replaced by a SET_RATE decision at the current rate, in an equivalent manner. It should be noted that for the AMR and AMR-WB coding the CMR is always present in each packet, and the case NO_REQ can be replaced by the current bit rate.
• step 517 an extended CMR request is prepared by writing the data associated with the extended CMR into the shared structure "BWJnfo.
• Figure 5c describes the operation of the transmitter upon receipt of a CMR request (normal or extended, other than NO_REQ). The steps remaining identical to the transmitter with respect to FIG. 4c are not repeated here for the sake of simplification.
• the encoding and transmission parameters are set as in the first embodiment.
• the transmitter can be left to decide when to enable redundancy.
• the test step is stopped and the redundancy at 522 is deactivated as described previously in the first embodiment.
• step 523 is implemented.
• step 523 it is checked whether an extended CMR request has been received ("updated” to "true” and “burst_uplink> 0" in the "CMR_Req" structure).
• the transmitter implements a rate increase test step by the transmission of redundant packets at 524 according to the information contained in the structure "CMR_Req". The rate is also set to encode the next frame based on the CMR received (at 525).
• RTCP packets may be used to indicate requests equivalent to the CMR used in the embodiments of the invention.
• FIG. 6 illustrates a hardware example of a communication terminal TA comprising a receiving device and an emitting device able to implement the methods of adapting the bit rate and determining an adaptation request according to the different embodiments. of the invention.
• the terminal TA comprises a storage space 11, for example a memory MEM, a processing unit 10 comprising a processor P, driven by a computer program PG, stored in the memory 11 and implementing the steps of the adaptation method and / or the method for determining a rate adaptation request within the meaning of the invention, and in particular the step of testing for increasing the coding rate implemented by a transmitting device by the transmission of data. at least one redundant packet according to selected transmission parameters, when these instructions are executed by the processor P.
• FIGS. 4a to 4c and FIGS. 5a to 5c show the steps of the algorithms of such computer programs.
• the code instructions of the program PG are for example loaded into a RAM memory (not shown) before being executed by the processor P of the processing unit 10.
• the program instructions can be stored on a memory card. storage medium such as flash memory, hard disk, or other non-transient storage media.
• the terminal TA comprises a communication module 12 capable of receiving the voice packets of an IP network and transmitting voice packets to the IP network with redundancy to test a rate increase according to the invention.
• the terminal comprises a transmitting device comprising a packet transmission unit able to implement a step of testing for increasing the coding rate by transmitting at least one redundant packet according to selected transmission parameters.
• the terminal also comprises a receiver device which, according to one embodiment, comprises an estimation module able to estimate an available bandwidth and a module for constructing and transmitting an adaptation request, able to build and transmit to a user. transmitting device, a request for implementing a coding rate increase test step by transmitting redundant packets according to selected transmission parameters.
• module can correspond to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
• a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .)
• the terminal is for example a telephone, a smartphone, a tablet, a computer, a residential gateway or a connected object.
• EVS_D (0 to 8) (9600, 13200, 16400, 24400, 32000, 48000, 64000, 96000, 12800)

Landscapes

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

Applications Claiming Priority (2)

Publications (1)

Family

ID=63638002

Family Applications (1)

Country Status (4)

Families Citing this family (6)

Family Cites Families (8)

• 2018
  • 2018-06-08 FR FR1855048A patent/FR3082386A1/fr not_active Withdrawn
• 2019
  • 2019-06-03 US US16/972,744 patent/US11349898B2/en active Active
  • 2019-06-03 WO PCT/FR2019/051301 patent/WO2019234338A1/fr unknown
  • 2019-06-03 EP EP19742839.4A patent/EP3804243A1/de active Pending

Also Published As

Similar Documents

Legal Events