EP3804243A1 - Adaptation de débit d'une session de communication en voix sur ip - Google Patents

Adaptation de débit d'une session de communication en voix sur ip

Info

Publication number
EP3804243A1
EP3804243A1 EP19742839.4A EP19742839A EP3804243A1 EP 3804243 A1 EP3804243 A1 EP 3804243A1 EP 19742839 A EP19742839 A EP 19742839A EP 3804243 A1 EP3804243 A1 EP 3804243A1
Authority
EP
European Patent Office
Prior art keywords
rate
cmr
request
adaptation
redundancy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19742839.4A
Other languages
German (de)
English (en)
Inventor
Stéphane RAGOT
Jérôme DUFOUR
Najmeddine MAJED
Minh Tri VO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP3804243A1 publication Critical patent/EP3804243A1/fr
Pending legal-status Critical Current

Links

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)

Abstract

La présente invention se rapporte à un procédé d'adaptation d'un débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu'il comporte une étape de test d'augmentation du débit de codage au dispositif émetteur par la transmission (428) d'au moins un paquet redondant selon des paramètres de transmission choisis (423). L'invention se rapporte également à un procédé de détermination d'une requête d'adaptation de débit de codage de signaux temps réels pour la mise en œuvre d'un test d'augmentation du débit de codage au dispositif émetteur par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis. L'invention se rapporte également à un dispositif émetteur, un dispositif récepteur mettant en œuvre les procédés décrits ainsi qu'un terminal comportant ces dispositifs.

Description

Adaptation de débit d'une session de communication en voix sur IP
La présente invention se rapporte au domaine des télécommunications et plus particulièrement au domaine des réseaux de communication par paquets. Dans ce type de réseaux, il est possible d'acheminer des flux de données associées à des services temps réel.
Le protocole Internet, appelé IP pour "Internet Protocol", développé par l'IETF, pour "Internet Engineering Task Force", est mis en oeuvre sur les réseaux de communication par paquets aussi bien pour supporter des services non temps-réel tels que des services de transfert de données, de consultation de pages web, de messagerie électronique, que des services temps réels ou conversationnels, tels que la téléphonie sur IP, la vidéo téléphonie sur IP ou encore la diffusion vidéo sur IP.
L'invention se rapporte plus particulièrement à une adaptation de débit de codage/décodage de signaux temps réels comme les signaux de voix ou de vidéo lors d'une session de communication temps-réel entre deux terminaux de communication.
Cette adaptation de débit et les mécanismes qui s'en rapportent sont adaptés pour la transmission de signaux numériques tels que des signaux audiofréquences (parole, musique ou autres), cependant ils s'appliquent à d'autres signaux temps réels comme la vidéo.
Un exemple de système de communication voix sur IP existant est décrit en référence à la figure 1. Cette figure décrit un système de communication bidirectionnelle de voix sur IP (VoIP) avec deux terminaux de téléphonie (100 et 150) reliés par un réseau par paquets de type IP (125). Le "plan de signalisation" n'est pas représenté sur cette figure mais les solutions possibles pour établir et gérer des appels peuvent reposer sur différents protocoles connus comme par exemple:
• SIP/SDP (pour « Session Initiation Protocol/Session Description Protocol » en anglais) selon les spécifications IETF RFC 3261 et RFC 4566 - comme dans les services multimédia sur IMS (pour « IP Multimedia SubSystem » en anglais). Pour faciliter les échanges de signalisation sur les capacités média et les offres/réponses associées, il est également possible d'utiliser « SDPcapneg » selon la spécification IETF RFC 5939.
• JSEP (pour « JavaScript Session Establishment Protocol » en anglais) qui utilise la syntaxe de SDP pour définir des descriptions de session WebRTC (avec un échange par WebSocket ou un autre moyen).
La figure 1 est une vue simplifiée du "plan média" et de la chaîne audio utilisée quand l'appel est établi entre 2 terminaux (100 et 150) reliés par un réseau IP (125). On se limite ici au cas d'un signal audio mono, le signal acoustique ambiant est par exemple capté par un microphone (101 et 151) de chaque côté de la communication. On remarquera que le cas d'un signal d'entrée / sortie mono peut facilement se généraliser à un cas multicanal où plusieurs micros et/ou haut-parleurs sont utilisés. De même, les microphones et haut-parleurs pourront être remplacés par des caméras et écrans dans le cas de signaux vidéo.
Le signal distant est restitué sur un haut-parleur (102 et 152). Les signaux audio captés et restitués subissent en général différents pré-/ post-traitements en émission et en réception (103 et 153) comme par exemple:
• En émission : conversion analogique/numérique, contrôle de gain, réduction de bruit, annulation d'écho, etc.
• En réception : conversion numérique/analogique, contrôle de gain, etc.
Le signal audio prétraité en émission est codé par trames successives - avec typiquement une longueur de trame de 20 ms - cette longueur est en général comprise entre 10 à 60 ms pour les applications conversationnelles. Les trames codées sont mises sous forme de paquets IP (104 et 154). Les paquets sont typiquement transportés par le protocole RTP (pour "Real Time Protocol" en anglais), décrit dans la spécification IETF RFC 3550, ce protocole se situe au-dessus des protocoles de transport IP/UDP (pour "User Datagram Protocol" en anglais). On notera que le protocole UDP peut être remplacé par un autre protocole de transport, par exemple par TCP (pour « Transmission Control Protocol » en anglais) pour notamment faciliter la traversée de réseaux avec traduction d'adresse réseau NAT (pour « Network Address Translation « en anglais), proxys ou pare-feux.
En réception (105 et 155), les paquets sont reçus dans un buffer de gigue visant à compenser les variations des temps de réception, et le signal est décodé (en compensant les pertes éventuelles de trames), enfin le signal reconstruit est post-traité (103 et 153) et restitué.
La communication est ici supposée bidirectionnelle et le système de communication forme ainsi un système bouclé avec rétroaction ("feedback"). Le « feedback » peut être transporté de deux façons:
• "Hors bande" (c'est-à-dire contenu dans des paquets qui constituent un flux supplémentaire par rapport au flux média RTP). Typiquement, le protocole RTCP (pour Real-Time Control Protocol) est utilisé comme canal de « feedback ». RTCP permet des transmissions de paquets de contrôle dans des paquets séparés du flux RTP. On rappelle que les paquets RTCP peuvent avoir une taille conséquente et donc résulter en un débit supplémentaire non négligeable; de plus, la perte possible de paquets peut être problématique, car si RTCP est utilisé à des fins d'adaptation, le feedback transporté peut être perdu. L'envoi des paquets par le protocole RTCP peut être discontinu et non répétitif, ce qui peut rendre l'adaptation moins réactive et dépendante des conditions réseaux (retard de transmission, pertes de paquets, etc.). En général, l'application doit supporter et utiliser le profil RTP AVPF (pour « Audio Video Profile with Feedback » en anglais) pour que RTCP soit réellement utilisable pour l'adaptation média. De plus, les applications de type voix sur IMS n'autorisent pour l'instant que le profil AVP (pour « Audio Video Profile » en anglais) qui restreint l'utilisation de RTCP; l'adaptation média dans les terminaux - si elle est utilisée - peut s'appuyer sur le "monitoring" des conditions réseaux, dont les informations contenues dans les rapports RTCP RR (Receiver Report) sur la perte de paquets ou la gigue qui sont envoyés en moyenne tous les 5 secondes.
• "Dans la bande" (c'est à dire dans le flux média RTP). Ce type de feedback peut être considéré comme plus robuste que RTCP car il est possible de répéter une même requête dans plusieurs paquets successifs. A noter que dans certaines situations (appel en attente, écoute de messagerie, ...), il est possible que les paquets RTP soient envoyés dans un seul sens, cependant on suppose ici un envoi de paquets RTP bidirectionnel pour que la rétroaction fonctionne. Un exemple de signalisation dans la bande est l'utilisation d'un champ CMR (pour « Codée Mode Request » en anglais) utilisé pour transmettre une requête d'adaptation de codage.
En général, plusieurs types de dégradation peuvent potentiellement affecter la qualité de la voix sur IP:
• bande passante variable / congestion du réseau
• perte, dé-séquencement, répétition de paquets
• retard des paquets (de transmission, de mise en file d'attente, de traitement...), variation du retard (gigue)
• dérive d'horloge entre les terminaux
Ils existent différentes solutions pour pallier ces dégradations différentes, dont des solutions d'adaptation dans les terminaux. On distingue deux types d'adaptation dans les terminaux VoIP: l'adaptation basée émetteur ("sender based" en anglais) et l'adaptation basée récepteur ("receiver based" en anglais). Il existe aussi des variantes où la décision d'adaptation est assistée ou prise par le réseau, mais ce cas n'est pas traité ici car il dépasse le cadre de l'invention.
Dans le cas d'une adaptation "basée émetteur", pour que l'émetteur puisse prendre une décision d'adaptation optimale de bout en bout, celui-ci doit recevoir un retour ou « feedback » du récepteur distant indiquant la qualité perçue en bout de chaîne, avec par exemple des indicateurs comme le taux de perte observé ou la bande passante disponible estimée par le récepteur distant.
Dans le cas d'une adaptation "basée récepteur", la décision d'adaptation est prise par le récepteur distant (155) et transmise par « feedback » vers l'émetteur local (104) (par exemple le choix du mode ou débit à utiliser) - ce feedback est transmis en passant par l'émetteur distant (154) puis le récepteur local (105). La figure 1 indique ce feedback par des flèches en pointillées pour le sens allant du récepteur 155 à l'émetteur 104. Bien entendu, ce feedback peut se faire dans l'autre sens de la communication, avec un feedback du récepteur 105 vers l'émetteur 154 en passant par les blocs 104 et 155; ce sens inverse n'est pas représenté sur la figurel pour ne pas alourdir cette figure.
On s'intéresse ici plus particulièrement à une adaptation en débit pour remédier par exemple aux changements de bande passante et à la congestion de réseau.
Dans un exemple de solutions d'adaptation, pour contrôler une variation de bande passante ou une congestion du réseau, on peut mettre en oeuvre les techniques décrites ci- dessous.
Lorsqu'un codée fonctionne à un débit fixe, une solution d'adaptation pour modifier le débit effectif sur le réseau consiste à varier le nombre de trames consécutives de signal dans un paquet ("frame bundling" en anglais) et ainsi varier le débit paquet ("packet rate" en anglais) et le débit relatif des entêtes protocolaires IP/UDP/RTP (et des couches inférieures).
Lorsqu'un codée est multi-débit, on peut également changer le débit du codée. Ce changement de débit peut se faire en fonction de la bande passante disponible estimée par le récepteur distant et reçue par « feedback » (décision "basée émetteur") ou en fonction d'une requête de changement de débit reçue par « feedback » (décision "basée récepteur").
La figure 2 décrit un exemple avancé de contrôle de débit d'un codée multi-débit appelé iSAC (pour « internet Speech Audio Codée » en anglais). Le codée iSAC est un codée propriétaire développé par la société GIPS (Global IP Solutions). Depuis 2011 le code source d'iSAC est disponible dans le projet open source WebRTC de Google Chromium™.
Le codée fonctionne selon deux modes différents :
• Le mode Wide Band (WB) code une bande audio de 0 à 8kHz avec une longueur de trames de 30 ou 60 ms.
• Le mode Super Wide Band (SWB) code une bande audio de 0 à 12kHz ou de 0 à 16kHz avec une longueur de trame de 30 ms.
Le débit du codée iSAC est variable ; le débit moyen peut aller de 10 à 32kbit/s en mode Wide Band et de 10 à 56 kbit/s en SuperWideBand. Le codée iSAC peut fonctionner selon deux modes de transmission sur le canal :
« Channel Adaptive »
« Channel Independent »
Le mode « Channel Adaptive » prend en compte les estimations de bande passante faites en réception par le décodeur iSAC et permet d'adapter le débit de codage, tandis que le mode « Channel Independent » se contente de suivre un débit cible (« target bitrate »). Comparée à la figure 1, on a volontairement omis à la figure 2 les blocs de traitements audio (103 et 153) et le réseau (125) afin d'alléger la figure. On retrouve les éléments de captation et restitution audio (blocs 101, 102 et 151, 152).
Le débit du codage (blocs 201, 251) est adapté dans le codée iSAC (blocs 202, 252) à partir de l'indication de débit dans le sens descendant, estimé au récepteur (blocs 205, 255).
En effet le récepteur (blocs 205, 255) estime la bande passante disponible dans le sens descendant (« downlink ») à chaque réception de paquets à partir des informations suivantes :
- taille du paquet (charge utile) ;
- temps d'arrivée ;
- numéro de séquence ;
- temps d'émission RTP.
Le débit estimé est ensuite mis à disposition de l'émetteur via une structure partagée (blocs 207 et 257). L'émetteur (blocs 204, 254) envoie un champ appelé BEI (pour « Bandwidth Estimate Index » en anglais) dont les valeurs vont de 0 à 23 pour indiquer la bande passante disponible estimée par le récepteur; le champ BEI indique une valeur de bande passante disponible ("bottleneck") estimée parmi des valeurs définies entre les débits cibles minimum et maximum du codée iSAC (de 0 à 11 en mode WB et de 0 à 23 en mode SWB). Le champ BEI est décodé à l'autre bout de la chaîne (blocs 203, 253).
On notera également que l'estimation de bande passante dans le codée iSAC s'accompagne également d'une estimation de la gigue qui n'est pas décrite ici mais qui sert à l'estimation de la taille du bourrage décrite plus loin; la gigue estimée est représentée sur 1 bit pour indiquer une valeur faible ou élevée et elle transmise dans le champ BEI en mode WB (0 si le BEI est entre 0 et 11 et 1 s'il est entre 12 et 23) ou codée dans le train binaire (charge utile de la trame courante) en mode SWB.
Pour le sens de transmission de 200 à 250, l'adaptation de débit est mise en oeuvre côté émetteur. Le codage effectué en 201 a un débit mis à jour par le bloc 202 à partir d'un champ BEI décodé en 203. Ce champ décodé a été codé en 254 à partir d'une estimation de bande passante disponible effectuée par le bloc 255 du récepteur 155.
La transmission dans l'autre sens s'effectue de la même façon avec les blocs correspondants.
Une méthode de bourrage ("padding" en anglais) de bits aléatoires, à la fin du paquet, est effectuée, pour tester s'il est possible d'augmenter le débit de codage ("bandwidth probing" en anglais). Cette méthode simple permet en effet d'augmenter artificiellement la taille de certains paquets à l'émission (210 ou 260 respectivement) afin de pouvoir estimer en bout de chaîne en réception (205 ou 255 respectivement) si la bande passante disponible sur le canal de transmission permet d'utiliser un débit supérieur au débit actuel. On notera cependant que cette méthode utilise des bits aléatoires sans autre utilité que le test de bande passante.
La taille et la décision d'envoi du bourrage de bits sont déterminées à l'aide d'un modèle de débit ("rate model" en anglais). Au début de l'appel (typiquement les 10 premières secondes), le débit est maintenu à un débit minimal. Ensuite trois paquets consécutifs comportant des bits de bourrage sont envoyés pour tester le canal, avec un intervalle maximal de typiquement 500 ms. La taille de ces paquets consécutifs est fixée pour que le débit instantané associé au paquet i soit donné par (1 + g ) Rir est la bande passante disponible estimée au paquet i et le terme adaptatif (de valeur supérieure >0) est calculé de façon "heuristique". Le principe est d'envoyer des pics de débit réguliers (« bursts ») sur le canal pour tester une augmentation de débit par rapport au débit actuel.
Le modèle de débit (« rate model ») mis en oeuvre dans les blocs 210 et 260 repose sur un modèle de goulot d'étranglement (« bottleneck ») limitant la bande passante disponible dans le réseau. Ce modèle de débit s'appuie sur plusieurs états internes définis au récepteur dont une détection binaire de dépassement ("overuse" en anglais) de la bande passante par le dernier paquet reçu avec une mesure du temps écoulé depuis le dernier dépassement détecté de bande passante (en ms), ainsi que des informations sur la file d'attente modélisant le "bottleneck" (nombre de paquets qui restent à transmettre, augmentation du retard).
L'estimation de débit effectuée au récepteur est en général efficace pour diminuer le débit de codage, c'est-à-dire détecter que la bande passante disponible est plus faible que le débit actuel et que le débit doit être abaissé. Par contre la méthode consistant à effectuer un bourrage de bits aléatoires pour vérifier que le débit actuel peut être augmenté n'est pas optimale, en effet, elle introduit des bits aléatoires non utilisés et non contrôlés. D'autre part, le codée iSAC produit un débit moyen qui peut être ajusté assez finement entre un débit minimal et un débit maximal (ex: 10 à 32 kbit/s ou 10 à 56 kbit/s), alors qu'un codée multi- débit fonctionnant selon un ensemble défini de débits discrets, comme un codée de type AMR, AMR-WB ou EVS, ne fonctionne pas sur une gamme continue de débits.
Par ailleurs, la méthode d'adaptation de débit du codée iSAC, utilisant une estimation de débit en réception et un test de canal par bourrage de bits, suppose l'utilisation d'un champ spécifique au codée iSAC (BEI). Ce champ spécifique n'existe pas pour d'autres types de codées, notamment pour les codées multi-débit de type AMR, AMR-WB et EVS. On notera que le champ CMR des codées AMR, AMR-WB et EVS est différent du champ BEI du codée iSAC, car l'un (BEI) représente une information sur la bande passante disponible estimée au récepteur et suppose une adaptation « basée émetteur », l'autre (CMR) permet de coder une requête d'adaptation indiquant un débit maximal et suppose une adaptation « basée récepteur ». Une autre méthode plus avancée - reprenant les mêmes principes - d'estimation de bande passante disponible et d'adaptation de débit de codage est décrite dans l'article "Making Google Congestion Control robust over Wi-Fi networks using packet grouping" de G. Carlucci, L. De Cicco, S. Holmer, S. Mascolo, publié dans ACM, IRTF & ISOC, Applied Networking Research Workshop, 2016. Cet article décrit le fonctionnement de l'algorithme GCC (pour "Google Congestion Control" en anglais) pour le contrôle de congestion vidéo; l'algorithme d'adaptation GCC est divisé en deux parties: une partie émetteur et une partie récepteur. L'algorithme GCC suppose l'utilisation du profil RTP AVPF pour envoyer des messages RTCP REMB (RTCP message for Receiver Estimated Maximum Bitrate) toutes les secondes ou dès que la bande passante estimée a baissé de 3%.
La partie émetteur est basée sur le taux de perte (« loss based »). Elle transmet dans les entêtes des paquets RTP des temps d'émission absolus appelés "abs-send-time", qui servent à l'estimation de bande passante disponible dans la partie récepteur. Elle utilise les rapports RTCP REMB indiquant le débit estimé Ar et la perte de trame observée ft par le récepteur distant pour adapter le débit de codage: le débit de codage cible As est respectivement augmenté, maintenu ou diminué quand le taux de perte est négligeable, faible ou élevé :
((l - 0.5/i)4s(i - l) si ! > 0,1
A < 0,02
As(i— 1) autrement
Le débit de codage réel est obtenu comme min (As, Ar), c'est-à-dire le minimum entre ce débit de codage cible et la dernière valeur de bande passante disponible estimée par le récepteur distant (reçue par RTCP).
La partie récepteur est basée sur la variation du retard unidirectionnel (« delay- based »). Elle utilise une machine à états finis avec 3 états (baisse, maintien, augmentation) et une estimation en réception de la bande passante disponible par filtrage de Kalman. L'estimation de bande passante s'appuie sur une modélisation de la variation du retard unidirectionnel (« one-way delay ») défini comme
dmi 0 = (tr( 0 - tr(i - 1)) - (ts( 0 - ts(i - 1))
Où ts(i) et tr(i) sont les temps d'émission (selon l'information "abs-send-time" envoyée dans l'entête RTP) et de réception du paquet i, sous la forme de deux composantes :
dm(i ) = m(t) + n(t)
Où m(i) est la variation du retard de file d'attente - estimée par filtrage de Kalman - et n(t) est la gigue réseau - considérée comme un bruit.
Le dépassement de la bande passante disponible ("overuse" en anglais) est détecté en appliquant un seuil adaptatif sur la variation estimée du délai de file d'attente m(i ) pour piloter les transitions entre les 3 états. L'estimation de débit en réception est adaptée selon les états : • Baisse : Ar(i) = aR(i ) où a e [0,85, 0,95] et R(i) est le débit mesuré sur les dernières 500 ms
• Maintien : Ar(Î) = Ar(i - 1)
• Augmentation : Ar(ï) = h Ar(i - 1) où h e [1,005, 1,3]
Cette méthode d'adaptation utilise des heuristiques pour l'adaptation et elle suppose qu'il est possible d'adapter le débit de façon fine avec des facteurs multiplicatifs (1,05 et h ) spécifiques pour l'augmentation de débit. Elle s'applique difficilement à des codées voix comme EVS qui sont multi-débits avec un ensemble de débits discrets. Par exemple, le ratio entre débits successifs pour le codée va de 1,11 à 1,5 pour le codée EVS avec des débits fixes de 7,2 à 128 kbit/s. De plus, l'utilisation de paquets RTCP (de type REMB ou autre) n'est pas toujours possible dans les applications de VoIP restreintes à un profil RTP tel qu'AVP (pour Audio Video Profile, défini dans IETF RFC 3551) qui limite l'intérêt de RTCP à des fins d'adaptation.
Pour les applications de téléphonie actuelles de type VoLTE (pour « Voice over LTE (Long Term Evolution) » en anglais désignant une technique de transport de la voix sur les réseaux de téléphonie mobile 4G LTE spécifiée dans GSMA IR.92 et de type VoWifi (pour « Voice over Wi-Fi » en anglais) désignant une technique de transport de la voix sur le réseau Wi-Fi spécifiée dans GSMA IR.65, des mécanismes d'adaptation du codage sont décrits dans le chapitre 10 de la spécification 3GPP TS 26.114 (utilisation de a=bw-info, ECN, ANBR, définition de CMR et RTCP-APP, etc.) avec des recommandations générales mais aucune obligation d'adaptation dans le service. Un exemple d'algorithme (informatif) d'adaptation pour la VoIP est décrit dans l'annexe C de la spécification TS 26.114. En pratique seul le profil RTP AVP est autorisé et l'adaptation pour la voix sur IMS est pour l'instant rarement autorisée et configurée par les opérateurs de réseaux mobiles qui préfèrent dimensionner le service avec un débit fixe garanti (GBR pour « Guaranteed Bit Rate »).
De plus, la spécification TS 26.114 contient des recommandations (voir clause 7.5.2.1.6) sur le débit de codage initial (ICM pour "initial codée mode" en anglais) à utiliser au début d'un appel pour éviter la congestion du lien et qu'il est recommandé - si aucune information de contrôle de débit n'a été reçue pendant une certaine période - d'augmenter graduellement le mode (débit) de codage au plus à la valeur de l'ICM correspondant au débit de codage autorisé; si aucune mauvaise qualité n'est détectée ou en l'absence d'information de contrôle de débit, il est recommandé que l'émetteur augmente son débit par paliers progressifs avec un certain délai d'attente de l'ordre de 500-600 ms. Cette approche d'adaptation est très heuristique. L'augmentation de débit repose sur le passage au mode de codage immédiatement supérieur, avec un monitoring des indicateurs de qualité ou l'attente d'une réception d'une requête par le récepteur (typiquement CMR ou RTCP-APP) pour valider l'augmentation de débit. Cette méthode n'est pas optimale car elle repose sur des heuristiques d'augmentation par paliers progressifs et provoque des sauts brusques de changement de débit avec des « tests en aveugle » de l'augmentation de débit.
Il existe ainsi un besoin d'une méthode d'adaptation de débit pour le codage/décodage qui pallie aux inconvénients précités.
L'invention propose à cet effet, un procédé d'adaptation d'un débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu'il comporte une étape de test d'augmentation du débit de codage au dispositif émetteur par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
Le fait de tester l'augmentation de débit par au moins une recopie d'une trame précédente appelés encore ci-après « paquets redondants », permet d'augmenter le débit sans sauts brusques puisqu'on peut définir les paramètres de transmission pour éviter de tester en aveugle le débit discret supérieur et risquer de dégradation la qualité sans pouvoir compenser les conséquences d'une augmentation directe du débit. Cette étape de test permet de vérifier si la bande passante disponible est suffisante.
De plus, la redondance des paquets peut être utilisée pour, par exemple, corriger les pertes de trames éventuelles, si l'augmentation de débit n'est pas justifiée et si elle crée un problème de congestion. Les paquets redondants servent alors à la fois pour tester l'augmentation de débit et aussi pour corriger des pertes de trames.
Selon un mode de réalisation, l'étape de test est mise en oeuvre tant qu'aucune requête d'adaptation de débit n'est reçue d'un dispositif récepteur.
Ainsi, lorsque le dispositif récepteur met en oeuvre une estimation de bande passante, il peut informer le dispositif émetteur d'un changement de débit supérieur ou inférieur. Dans les deux cas, le test s'arrête pour effectuer le changement de débit demandé.
Dans un mode de réalisation particulier, l'étape de test est mise en oeuvre après un changement de débit au débit discret inférieur.
Ce processus permet ainsi de moduler encore plus l'augmentation de débit (augmentation moins brusque) mais elle peut cependant introduire des dégradations dans le signal transmis.
Dans un mode de réalisation, l'étape de test est mise en oeuvre lorsqu'une temporisation a atteint un seuil depuis la dernière requête d'adaptation reçue d'un dispositif récepteur.
Ainsi, si le débit de codage n'a pas été adapté depuis un certain temps, alors une augmentation de débit est sans doute possible et un test d'augmentation est alors approprié. Dans un mode de réalisation, la temporisation pour déclencher le test d'augmentation est adaptée en fonction d'une information de bande passante disponible estimée au dispositif récepteur..
Ainsi, selon l'état du réseau et la bande passante disponible, on peut définir un temps plus court pour tenter une augmentation de débit si par exemple la bande passante disponible a tendance à augmenter ou au contraire définir un temps plus long quand la bande passante estimée a tendance à diminuer.
Dans un mode de réalisation possible, l'étape de test est mise en oeuvre en fonction d'une information d'évolution du débit de codage obtenue.
Dans le cas où la tendance d'évolution du débit de codage est plutôt à la baisse, alors il n'y a pas lieu d'effectuer un test d'augmentation du débit de codage.
Dans un mode de réalisation avantageux, l'information d'évolution du débit de codage est obtenue à partir d'un historique de bande passante disponible estimée au dispositif récepteur.
Ainsi, les différentes estimations de bande passante disponible au niveau d'un dispositif récepteur permettent d'obtenir une tendance d'évolution de cette estimation et d'en déduire une information d'évolution de la bande passante disponible.
Dans un autre mode de réalisation, l'étape de test est mise en oeuvre après réception d'une requête d'adaptation reçue d'un dispositif récepteur et comportant une demande de transmission de paquets redondants selon des paramètres de transmission choisis.
Ainsi, dans ce mode de réalisation, c'est le dispositif récepteur qui détermine la pertinence de la mise en oeuvre d'une étape de test selon des estimations de bande passante effectuées. La requête d'adaptation est par exemple déterminée au dispositif récepteur, en fonction de la bande passante disponible estimée.
La présente invention vise également un procédé de détermination d'une requête d'adaptation de débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteurs et des dispositifs récepteurs de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu'il comporte une étape d'estimation d'une bande passante disponible pour un dispositif récepteur et de construction d'une requête d'adaptation à transmettre à un dispositif émetteur et comportant une demande de mise en oeuvre d'une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
Ainsi, à partir d'une estimation de bande passante effectuée au niveau d'un dispositif récepteur d'un terminal, celui-ci peut déterminer s'il est pertinent d'effectuer une étape de test au niveau d'un dispositif émetteur pour augmenter le débit de codage. Une requête d'adaptation est alors construite en conséquence. L'invention vise également un dispositif émetteur d'un terminal de communication apte à mettre en oeuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets. Le dispositif émetteur est tel qu'il comporte une unité de transmission de paquets apte à mettre en oeuvre une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
Ce dispositif présente les mêmes avantages que le procédé d'adaptation décrit précédemment, qu'il met en oeuvre.
L'invention vise aussi un dispositif récepteur d'un terminal de communication apte à mettre en oeuvre des sessions de communication temps réel et comportant un codeur multi- débits selon un ensemble de débits discrets. Le dispositif est tel qu'il comporte un module d'estimation apte à estimer une bande passante disponible et un module de construction et de transmission d'une requête d'adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en oeuvre d'une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
Ce dispositif présente les mêmes avantages que le procédé de détermination d'une requête d'adaptation décrit précédemment, qu'il met en oeuvre.
L'invention vise également un terminal de communication comportant un dispositif émetteur tel que décrit et/ou un dispositif récepteur tel que décrit.
L'invention vise un programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé d'adaptation tel que décrit et /ou des étapes du procédé de détermination d'une requête tel que décrit, lorsque ces instructions sont exécutées par un processeur.
Enfin, l'invention se rapporte à un support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l'exécution du procédé d'adaptation tel que décrit et /ou des étapes du procédé de détermination d'une requête tel que décrit.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels:
- la figure 1 illustre un système de communication de VoIP connu de l'état de l'art et précédemment décrit ;
- la figure 2 illustre une méthode d'adaptation de débit connue de l'état de l'art et utilisée avec le codée iSAC précédemment décrit ; - la figure 3 illustre un mode de réalisation d'un système de communication voix sur IP selon un mode de réalisation de l'invention ;
- les figures 4a à 4c illustrent sous forme d'organigrammes les étapes d'un procédé d'adaptation d'un débit de codage dans un premier mode de réalisation de l'invention;
- les figures 5a et 5c illustrent sous forme d'organigrammes les étapes d'un procédé d'adaptation d'un débit de codage dans un deuxième mode de réalisation de l'invention ainsi que les étapes d'un procédé de détermination d'une requête d'adaptation de débit selon un mode de réalisation de l'invention ;
- la figure 6 illustre un exemple matériel d'un terminal de communication incorporant un dispositif émetteur et un dispositif récepteur, selon un mode de réalisation de l'invention.
En référence à la figure 3, un système de communication bidirectionnelle avec adaptation de débit et utilisation de redondance selon un mode de réalisation de l'invention est maintenant décrit.
La communication est effectuée entre 2 terminaux A et B. On retrouve les éléments de captation et restitution audio (blocs 101, 102 et 151, 152) déjà présentés en rapport avec la figure 1. Sans perte de généralité on suppose ici que le codage s'effectue avec le codée EVS restreint aux modes « EVS Primary SWB » sur une gamme de débits possibles allant de 9.6 à 128 kbit/s. Dans des variantes de l'invention, on pourra utiliser le codée EVS sur une gamme de débit plus restreinte, par exemple de 9.6 à 24.4 kbit/s ou considérer également un changement possible de bande audio, avec des débits fixes par exemple de 7.2 (NB+WB) à 24.4 (NB+WB+SWB) kbit/s en utilisant la bande codée maximale à chaque débit. Dans des variantes, on pourra aussi utiliser d'autres codées, comme par exemple AMR ou AMR-WB sur une gamme de débits allant respectivement de 4.75 à 12.2 kbit/s (pour AMR) et 6.6 à 23.85 kbit/s (pour AMR-WB).
Le débit du codage à l'émetteur (blocs 301, 351) est adapté selon l'invention en utilisant de façon privilégiée une signalisation dans la bande ("in-band") pour indiquer les requêtes d'adaptation avec un champ CMR présent dans la charge utile (payload) des paquets pour le codée EVS. Ce type de signalisation in-band est robuste - dans le sens où il peut être répété dans des paquets RTP successifs si nécessaire - et ne dépend pas des contraintes sur les instants d'envoi de paquets pour RTCP. Pour des codées n'ayant pas de champ CMR dans leur charge utile (payload), on pourra dans des variantes définir un champ de fonctionnalité équivalente ou utiliser une signalisation hors bande par RTCP (par exemple RTCP REMB); dans la suite on suppose que la signalisation de requête d'adaptation se fait dans la bande par CMR.
On suppose qu'à l'établissement d'appel, le payload RTP du codée EVS est configuré avec un mode « header-full » (hf-only= l) et un CMR systématique (cmr= l). On renvoie le lecteur à la spécification du payload RTP d'EVS dans la spécification 3GPP TS 26.445 Annexe A pour la définition des paramètres SDP (cmr, hf-honly, ...) et aussi sur les modes de « paquétisation » (Compact ou Header-Full) du codée EVS. On rappelle que le code CMR appelé NO_REQ du codée EVS indique que le CMR ne contient pas de requête, et donc que l'information CMR peut être ignorée; cela permet donc d'envoyer des paquets sans requête, même quand l'envoi du CMR est systématique. Dans des variantes de l'invention il sera possible d'utiliser d'autres configurations SDP, comme cmr=0 (envoi de CMR à la demande, uniquement quand un CMR doit être envoyé) ou hf-only=0 (utilisation du mode Compact sauf quand le mode Header-Full est nécessaire, par exemple lorsqu'une trame redondante est ajoutée au paquet courant).
Par ailleurs, dans un mode de réalisation privilégié on suppose que la transmission discontinue (DTX pour « Discontinuous Transmission »), où les trames inactives sont transmises en moyenne toutes les 160 ms par des descripteurs de silence (SID pour Silence Description), est désactivée par le paramètre SDP dtx=-l du codée EVS. Cela permet d'assurer un test continu de la bande passante sur le canal. Cependant, dans des variantes de l'invention, le mode DTX sera activé pour le codée EVS, ce qui implique que l'invention ne sera appliquée que dans les périodes de signal actif, car il n'est pas pertinent de modifier le mode de transmission discontinue de trames SID afin de préserver une efficacité maximale du mode DTX quand celui-ci est activé. On rappelle que pour les codées AMR et AMR-WB il n'est pas possible de contrôler le mode DTX au niveau SDP, si bien que ce mode DTX est par défaut toujours activé.
Lorsque la négociation de l'appel utilise le protocole SDP, ce qui est le cas dans les modes de réalisation décrits ici, l'utilisation de la redondance au niveau applicatif ("application layer redundancy") dépend du paramètre SDP "max-red". Typiquement le paramètre "max- red" donne la durée maximale (en ms) - à l'émetteur - entre la transmission d'une trame (dite primaire) et la transmission d'une version redondante; ce paramètre permet donc de fixer un retard maximal lorsque la redondance est utilisée. Par exemple "max-red=20" indique qu'il est possible d'utiliser la redondance et qu'une trame redondante peut être transmise jusqu'à 20 ms après la trame originale. En général, quand "max-red" est fixé à 0, cela revient à désactiver l'utilisation de la redondance et si "max-red" n'est pas présent comme paramètre de signalisation (attribut SDP), cela indique qu'aucune limitation n'existe sur l'utilisation de la redondance - dans la limite où la bande passante globale spécifiée par le paramètre SDP « b=AS : » selon l'IETF RFC 4566 et les modes de codage autorisés dans la session sont respectés. On suppose ici que le paramètre SDP "max-red" n'est pas défini ou que sa valeur est suffisante pour pouvoir appliquer l'invention (par exemple max-red=220). Le récepteur (blocs 308 et 358) reçoit les paquets RTP successifs. Dès qu'un nouveau paquet est reçu, le champ CMR - s'il est présent - est extrait (blocs 307 et 357) et le contenu de ce champ CMR est écrit - sauf dans le cas « NO-REQUEST » (NO_REQ) ou si le champ CMR n'est pas présent - dans une structure appelée "CMR_Req" en 306 et 356, qui est partagée entre l'émetteur et le récepteur dans un même terminal. Dans un exemple de réalisation, la structure CMR_Req comprendra plusieurs entrées:
• une entrée booléenne appelée "updated" qui indique si un nouveau CMR a été reçu (prenant pour valeurs "vrai" ou "faux")
• une entrée appelée "requested_bitrate" qui indique le débit de codage (maximal) demandé dans le CMR
On notera que les blocs 307 et 357 sont intitulés "Ext. CMR_A/B" afin de couvrir le cas général d'une requête CMR étendue utilisée dans le deuxième mode de réalisation; dans le premier mode de réalisation la requête CMR sera une requête classique.
Dans des variantes, on pourra compléter ces entrées par d'autres informations comme "requested_bandwidth" pour indiquer la bande audio codée demandée (NB, WB, SWB, FB) dans le CMR, et des entrées appelées par exemple "activate_ca_mode" / "ca_fec_mode" / "ca_offset" pour contrôler respectivement l'activation du "channel-aware mode" et les paramètres du channel-aware mode ("FEC mode" valant LO ou HI et "offset" valant -1, 0, 2, 3, 5, ou 7).
Dans une réalisation typique, l'émetteur et le récepteur sont exécutés en parallèle (par exemple dans des files d'exécution ou "threads" différents) ; cette structure partagée est alors nécessaire et l'accès à cette structure se fait typiquement dans une section critique avec l'usage d'une mutex pour gérer des accès en parallèle.
Le champ CMR à envoyer est construit et codé par les modules de codage du champ CMR 302 et 352. Le champ CMR reçu est extrait par les modules d'extraction 307 et 357. Le champ CMR peut être, soit selon un premier mode de réalisation de l'invention, un champ CMR classique avec des codes définis pour les codées tels que AMR, AMR-WB ou EVS, soit selon un deuxième mode de réalisation de l'invention, un champ CMR étendu comme décrit ultérieurement dans le deuxième mode de réalisation. Dans ce deuxième mode de réalisation, on utilise un CMR étendu pour indiquer l'activation d'une transmission redondante.
On se restreint dans le mode de réalisation privilégié à un usage du codée EVS en mode Primary SWB pour simplifier la description. Les paramètres de codage et d'émission adaptés selon l'invention sont dans ce cas le débit de codage et l'utilisation de redondance 100%. Dans des variantes, plus de paramètres d'émission pourraient être considérés pour l'adaptation, par exemple la bande passante (NB, WB, SWB ou FB) dans le cas du codée EVS - si la gamme de débit utilisée pour l'adaptation permet aussi de changer de bande codée -, le type de redondance (par exemple une redondance partielle, ou une redondance à plus que
100%),
La redondance est ici définie comme un mode de transmission avec répétition de trames codées au niveau applicatif, comme décrit dans le chapitre 10 de la spécification 26.114. On considère plus particulièrement l'utilisation de la redondance dite à 100% qui implique que le paquet courant contient la charge utile (payload) de la trame courante et la charge utile (payload) d'une trame précédente décalée d'un offset prédéterminé. Ainsi ce type de redondance revient à (approximativement) doubler le débit instantané de transmission (en supposant que le débit de la trame courante et celui de la trame redondante sont identiques) par la recopie d'un paquet précédent de façon ponctuelle, dans un mode de réalisation.
On renvoie le lecteur au chapitre 10 de la spécification 3GPP TS 26.114 pour des illustrations de cas de redondance avec les codées AMR, AMR-WB et EVS, où la trame codée N est répétée dans un paquet suivant avec une distance appelée "offset" et notée ici K . Quand K = 1, le paquet N contient la trame N et la trame précédente N - 1 , tandis que quand K = 2 le paquet N contient la trame N et la trame N - 2 ainsi qu'une trame vide (NO_DATA). Pour un offset K plus grand, le nombre de trames vides (NO_DATA) "insérées" entre la trame courante d'indice N et la trame redondante d'indice N - K est K - 1 . On notera qu'il est possible de combiner la redondance avec l'agrégation de trames, mais ce cas n'est pas détaillé ici (voir 3GPP TS 26.114 figures 10.12 et 10.13).
Selon l'invention, les paramètres d'émission (débit, activation de redondance) sont fournis par le bloc 305, 355 au codeur/à l'émetteur (bloc 301, 351) qui applique ces paramètres lors du codage et de la transmission de la prochaine trame codée (ou des prochaines trames codées) jusqu'à réception d'une nouvelle requête CMR.
On suppose ici que le débit initial de codage est fixé au débit le plus faible autorisé dans la session, en supposant qu'il n'existe aucune garantie de qualité de service (QoS). Cependant dans des variantes, ce débit initial pourra être défini comme le débit maximal autorisé (si on dispose d'informations sur une garantie de débit « GBR » ) ou un débit intermédiaire prédéterminé entre le débit minimal et le débit maximal.
A la réception d'un nouveau paquet RTP, une estimation de bande passante est réalisée (blocs 304 et 354). Dans un mode de réalisation cette estimation sera similaire à l'estimation réalisée dans le codée iSAC à partir des informations sur le dernier paquet reçu (en ayant conservé l'historique de l'analyse réalisée à partir des paquets précédents):
- taille du paquet (charge utile RTP hors entêtes protocolaires)
- temps d'arrivée
- numéro de séquence (champ RTP) - timestamp (champ RTP)
Cette estimation de bande passante disponible est effectuée chaque fois qu'un nouveau paquet RTP est reçu par le récepteur. Dans des variantes, on pourra utiliser une estimation différente de l'estimation de bande passante au récepteur, par exemple l'estimation de l'algorithme de contrôle de congestion GCC, ou d'autres méthodes d'estimation de bande passante disponible à partir des mêmes informations sur la réception des paquets ou d'informations dérivées comme le taux de perte estimé ou la gigue estimée.
On suppose ici que l'historique de la bande passante estimée lors de la réception des paquets sur une durée prédéterminée, par exemple 500 ms, incluant le paquet qui vient d'être reçu, est stocké dans le bloc 304 et 354, et qu'une structure partagée appelée "BWJnfo" en 303 et 353 est définie pour pouvoir communiquer à l'émetteur qu'un nouveau CMR doit être envoyé et les informations associées à ce CMR. Dans un exemple de réalisation, la structure "BWJnfo" comprend les entrées suivantes:
• une entrée booléenne appelée "updated" qui indique si un nouveau CMR sera à envoyer (prenant pour valeurs "vrai" ou "faux")
• une entrée appelée "requested_bitrate" qui donne le débit de codage correspondant à la bande passante disponible estimée par le récepteur
Dans des variantes de l'invention il sera possible de compléter ces entrées par des informations complémentaires permettant de construire une requête CMR pour changer de bande audio codée, d'activer le "channel-aware mode" du codée EVS. Dans le second mode de réalisation, les structures "BWJnfo" et "CMR_Req" comprendront également un champ appelé "burst_uplink" associée à une requête CMR étendue, comme expliqué plus loin dans le deuxième mode de réalisation.
A partir de l'historique de bande passante disponible estimé en 304, 354, il est possible de prendre en compte non seulement la valeur instantanée de la bande passante (mise à jour lors de la réception du dernier paquet), mais aussi sa tendance sur l'horizon temporel défini par l'historique (ici par exemple 500 ms). On considère ici à titre d'exemple que la tendance d'évolution de la bande passante disponible est estimée par une simple régression linéaire. On pourra ainsi calculer la pente du modèle linéaire y=f(x) où x est le temps d'arrivée des paquets (en secondes ou ms) et y est la bande passante disponible estimée. Cette pente (aussi appelée coefficient directeur) est par exemple donnée de façon analytique sous la forme : å(** - x) (y* - ÿ)/ å(x, - x)2 où (¾,y sont le temps de réception et la bande passante estimée lors de la réception du paquet i, x et ÿ sont les moyennes des xt et yt sur l'horizon temporel considéré. Dans des variantes on pourra utiliser des variantes robustes de régression linéaire, avec une régularisation selon la norme L1 ou L2. Dans des variantes on pourra aussi utiliser une estimation de tendance dérivée de l'estimation de bande passante disponible (ce qui est par exemple possible si un filtrage de Kalman est utilisé comme dans l'algorithme GCC). Avant le codage de la prochaine trame, la requête extraite est lue et convertie (blocs 305 et 355) en paramètres de codage/d'émission, qui sont listés ci-dessous :
• le débit de codage à utiliser
• l'utilisation de redondance 100%
On remarquera que la taille du payload RTP est souvent légèrement supérieure à la "charge utile nette" associée au débit de codage. Par exemple, pour un codage de type EVS avec un mode de transport "Header-full" et avec un CMR systématique (hf-only= l, cmr= l), deux octets sont systématiquement rajoutés à la trame codée pour constituer le payload.
Un dépassement supplémentaire ("overhead") peut également être présent dans un contexte de transmission, comme par exemple avec la technologie WebRTC, où des extensions d'entête RTP sont utilisées, ce qui rajoute des octets supplémentaires aux paquets RTP. Par exemple pour une communication voix, 12 octets peuvent être rajoutés dans l'entête RTP si la configuration suivante est utilisée:
• Une extension d'entête de type « one-byte » selon la RFC 5285 (avec un préambule OxBEDE sur 2 octets et un champ de longueur indiquant "length=2" sur 2 octets pour signaler que 2 types d'extension sont ajoutées), pour un sous-total de 4 octets.
• Une extension « one-byte » sur 2 octets, de type :
a=extmap : 1 urn : ietf : params : rtp-hdrext : ssrc-audio-level
• Une extension « one-byte » sur 4 octets de type :
a=extmap:3 http://vfww.webrtc.org/experiments/rtp-hdrext/abs-send-time
• Un bourrage de 2 octets nuis.
Dans une autre configuration un seul type d'extension (par exemple l'extension ci-dessus de type "ssrc-audio-level") pourrait être utilisé, ce qui ne rajouterait que 8 octets supplémentaires.
Si ce débit supplémentaire n'est pas pris en compte (retranché de la taille du paquet RTP) dans l'estimation de bande passante disponible au récepteur, cela revient à tester un débit plus élevé que le mode de codage actuel. Ainsi, la bande passante réellement utilisée pour une trame donnée (sans redondance 100%) sera biaisée vers une valeur de débit de codage plus élevée, à cause des octets supplémentaires dans l'entête RTP si les entêtes RTP ne sont prises en compte qu'après estimation de bande passante. Dans le mode de réalisation privilégié, on éliminera ce biais en ne donnant à l'estimation de bande passante disponible (bloc 304, 354) que la taille de la charge utile sans les entêtes RTP. Dans des variantes de l'invention il sera prévu de ne pas éliminer ce biais, et on supposera que le récepteur compensera ce biais avant de former le CMR à envoyer.
On présente d'abord un premier mode de réalisation où l'émetteur et le récepteur agissent de manière coordonnée et où la décision d'activer la redondance est prise par l'émetteur à partir des informations sur la réception de CMR et du débit actuel. Le débit actuel est en particulier utilisé, pour vérifier s'il correspond au débit maximal autorisé dans la session, auquel cas la redondance n'est pas activée. Selon ce premier mode de réalisation, l'émetteur décide de tester le canal en envoyant des paquets avec redondance, après un certain délai avant de déclencher un test d'augmentation de débit. Dans un premier mode de réalisation, on considère d'abord le cas où chaque paquet issu de ce test contient de la redondance. Dans un autre mode de réalisation plus optimisée, la redondance ne sera envoyée que par intermittence pour limiter le pic de débit moyen occasionné par le test du canal. Dans ce premier mode de réalisation, l'initiative de décision sur la redondance revient à l'émetteur.
On rappelle que la logique "normale" du champ CMR pour les codées AMR, AMR-WB, et EVS est d'indiquer qu'il ne faut pas dépasser un débit maximal indiqué par le CMR; selon l'invention; l'émetteur doit donc normalement respecter cette contrainte, qui est particulièrement importante dans les cas d'interopérabilité avec les systèmes mobiles en mode circuit qui peuvent avoir un débit maximal de codage (par exemple 12,65 kbit/s pour AMR-WB) inférieur à celui autorisé en voix sur LTE (par exemple 23,05 kbit/s). Ainsi, pour préserver l'interopérabilité avec d'autres systèmes (dont les passerelles d'interopérabilité), il sera prévu dans ce premier mode de réalisation de définir un paramètre SDP "adapt", et dont l'utilité sera de vérifier que les deux terminaux en communications sont bien compatibles avec l'invention. Dans ce cas, la logique du champ CMR pourra être modifiée pour permettre à l'émetteur de dépasser temporairement la limite imposée par le dernier CMR reçu, afin de tester une augmentation de débit (qui par nature ne respecte par la contrainte de débit maximal du dernier CMR reçu). Si un terminal implémentant l'invention communique avec un autre terminal non compatible avec le paramètre SDP "adapt", l'invention ne pourra pas être utilisée car elle suppose que le terminal distant envoie par CMR un débit correspondant à une bande passante estimée en réception, ce qui ne serait pas le cas.
Dans ce mode de réalisation, quand la bande passante disponible estimée au récepteur est différente du débit actuel observé par le récepteur (à partir du dernier paquet reçu), un CMR est envoyé pour changer de débit. Cette approche est en particulier suffisante pour réduire le débit, car l'estimation de bande passante selon l'état de l'art fonctionne en général assez bien pour détecter qu'il faut baisser le débit actuel quand celui-ci dépasse la capacité du canal. En effet, lors d'un début de congestion, le récepteur observera une augmentation du délai de file d'attente ou du taux de perte. Cependant, quand le débit actuel est inférieur à la bande passante disponible, la bande passante est en général sous-estimée si un test d'augmentation de débit n'est pas mis en œuvre..
Ainsi pour pouvoir augmenter le débit, l'émetteur envoie selon l'invention des paquets contenant de la redondance pour tester le canal. Si des pertes sont causées par cette augmentation de débit, elles pourront être compensées par la redondance. Le fait d'utiliser la redondance permet de tester le canal avant d'augmenter réellement le débit et de compenser les pertes induites de façon proactive.
On fixe dans ce mode de réalisation les paramètres d'adaptation suivants qui définissent les caractéristiques des paquets de redondance ou « bursts » selon un exemple suivant de valeurs:
• durée (maximale) de redondance: Lburst = 100 (définie en nombre de trames);
• offset de redondance: Kburst (sa valeur est fixée à une valeur >0, par exemple à 2, en cours de redondance, et elle vaut -1 quand la redondance est désactivée), on verra plus loin que l'offset pourra aussi prendre une valeur qui sera fonction d'un paramètre de fréquence d'envoi de redondance;
• temps écoulé (« ti mer ») depuis le dernier CMR reçu : TcMR réinitialisé à 0 à chaque réception de CMR (avec un débit donné, autre que NO_REQ);
• délai de déclenchement du test d'augmentation de débit par redondance :
Tburst (défini en nombre de trames) fixé à 250
• facteur d'ajustement contrôlant le délai de déclenchement du test: fburst (sa valeur est adaptée mais ré-initialisée à 1.0) ;
• paramètre d'adaptation du facteur fburst : <p6urst = 1.5.
Dans des variantes, d'autres valeurs pourront être affectées aux paramètres ci-dessus.
Les figures 4a, 4b et 4c représentent un exemple d'implémentation d'un procédé d'adaptation de débit avec redondance selon l'invention sous la forme d'organigrammes, mis en oeuvre dans un système bidirectionnel.
La figure 4a présente les étapes mises en oeuvre par le récepteur selon un premier mode de réalisation de l'invention, à la réception d'un paquet.
Dans ce mode de réalisation, la communication est bidirectionnelle et les étapes suivantes peuvent être appliquées dans les deux terminaux.
A la réception d'un paquet (en 401), deux types d'information sont extraits :
• des informations de transmission du paquet actuel permettant l'estimation de la bande passante disponible (en 402) selon une des méthodes d'estimation précédemment décrites. L'extraction de ces informations est suivie par les étapes X décrites en référence à la figure 4b ;
• des informations sur le type d'adaptation demandé à partir de la requête CMR envoyée par l'autre bout de la communication (en 403). Le CMR extrait est indiqué dans la structure partagée "CMR_req", en particulier pour signaler qu'un nouveau CMR a été reçu si celui-ci est présent et différent de NO_REQ. L'entrée "updated" de la structure CMR_Req est mise à la valeur "vrai" quand un CMR (autre que NO_REQ) a été extrait. On rappelle que, pour le codée EVS, le champ CMR est codé sur un octet appelé "CMR byte" et qu'il est construit à partir de 3 champs: H ("header" à 1 bit), T ("type" sur 3 bits) et D ("data" sur 4 bits) selon les tableaux A.2 et A.3 de l'annexe A de la spécification 3GPP TS 26.445. On peut donc extraire le débit DCMR demandé et éventuellement d'autres paramètres de codage (comme la bande codée) en décodant le CMR (si celui-ci est reçu et autre que la valeur NO_REQ correspondant à T= l ll et D= ll l l en binaire).
On ne détaille pas ici les étapes connues de l'homme de l'art qui consistent à extraire les entêtes (champs CMR et ToC pour "Table of Content" si présents), à démultiplexer et décoder les trames codées à partir de la charge utile du paquet reçu pour le codée EVS. En particulier, en cas de pertes de paquet, la redondance éventuelle sera utilisée par le récepteur pour corriger des pertes si la trame courante perdue a été dupliquée dans un autre paquet avec un offset donné.
La figure 4b détaille les étapes X mises en oeuvre au récepteur après extraction des informations sur le paquet actuel (402). Une estimation de la bande passante est faite selon l'une des méthodes précédemment décrite (en 411). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 412) pour déterminer s'il y a besoin de changer le débit de réception actuel et s'il est possible de passer d'un débit discret à un autre.
Dans le mode de réalisation privilégié cette correspondance est mise en oeuvre selon le pseudo-code donné en Annexe 1 pour obtenir le débit D à partir de la bande passante disponible B.
Dans des variantes, on pourra modifier cette correspondance en prenant par exemple le débit discret du codée EVS supérieur ou inférieur le plus proche de la bande passante estimé.
Si le débit estimé est équivalent au débit actuel (N en 413), aucune information de débit (bloc 414) n'est écrite dans la structure partagée "BWJnfo" et l'entrée "updated" de cette structure est mise à la valeur "faux". Si le débit estimé est différent du débit actuel (O en 413), on écrit dans la structure partagée "BWJnfo" les informations nécessaires à l'étape 415 (la valeur de l'entrée "requested-bitrate") pour que l'émetteur puisse coder le CMR avec la prochaine trame à envoyer, en fixant aussi la valeur de l'entrée "updated" à "vrai". Une requête classique de changement de débit à un débit discret correspondant sera alors construite et codée comme dans le cas d'un codée EVS de l'état de l'art.
La figure 4c détaille les étapes mises en oeuvre à l'émetteur (incluant le codeur) d'un procédé d'adaptation de débit de codage selon un premier mode de réalisation de l'invention. Lors de la réception d'une nouvelle trame de signal à coder (étape 420), l'émetteur vérifie si un CMR a été reçu dans la structure partagée "CMR_Req" en 421 (en vérifiant si l'entrée "updated" est passée à "vrai"). Si c'est le cas, il réalise une adaptation des paramètres de codage et d'émission (en 424), si un CMR comportant une requête d'adaptation existe, puis il met la valeur de l'entrée "updated" de la structure CMR_Req à "faux". De plus, si un CMR a été reçu avec un débit demandé différent du débit de codage actuel, une indication de réception de CMR est mise en mémoire et le compteur de trame depuis le dernier CMR reçu est remis à 0 (TCMR = 0) à l'étape 424.
En 425, on vérifie si un test d'augmentation de débit avec redondance est en cours, en vérifiant si Nburst ³ 0. Si c'est le cas (O en 425), alors ce test est désactivé en 426. On réinitialise en 426 les paramètres de redondance avec Nburst = -1 (Nhurst représentant le nombre de trames avec redondance qui reste à transmettre) et Kburst = -1. De plus, le délai de déclenchement du test d'augmentation de débit est adapté selon l'adaptation de débit demandée dans la requête CMR.
Ainsi;
• Si le débit de codage actuel est supérieur au CMR reçu ( Rs > RCMR) le récepteur demande de baisser le débit. Il est alors décidé d'augmenter la temporisation pour un déclenchement d'un test d'augmentation de débit. Pour cela, on augmente le facteur d'ajustement en fixant fburst = fburst + <p6urst . La temporisation pour déclencher un test est comme expliqué ultérieurement, fonction du facteur fburst selon la formule suivante :
^CMR— fburst· t bur st
• Sinon le récepteur distant demande d'augmenter le débit ( Rs < RCMR ) et on choisit de réduire le délai de déclenchement d'un test d'augmentation de débit en adaptant le facteur selon la formule fburst = fbUrstl<Pburst On pourra également ajouter une condition d'intervalle temporel minimal avec par exemple l'étape supplémentaire: fburst <- max(Jburst, 0.15).
Cette logique d'adaptation suit le principe AIMD ("Additive Increase Multiplicative Decrease") de contrôle de congestion.
S'il n'y a pas de CMR reçu dans la structure partagée ou si le CMR ne comporte pas de requête d'adaptation (NO_REQ), alors l'étape 422 est mise en oeuvre.
En 422, l'émetteur vérifie si un test d'augmentation de débit est à mettre en oeuvre. On vérifie que les conditions pour activer un test d'augmentation du débit de codage sont vérifiées. Plus précisément, dans le mode de réalisation privilégié, il est décidé de tester une augmentation de débit en 422 si les conditions suivantes sont simultanément remplies:
• Si le débit actuel Rs est inférieur au débit maximum R ax autorisé dans la session. Sinon, si Rs = R ax, il n'y a pas de test mis en oeuvre (429). On pourra aussi réinitialiser fburst = 1. • Si le temps écoulé depuis la dernière requête CMR reçue TcMR (défini comme le nombre de trames depuis le dernier CMR) est supérieur à une temporisation prédéterminée TCMR (par exemple 500 ms). On prend ici TCMR = fhurst· Thurst dans des variantes on pourra fixer par exemple rCMfl =250 trames de 20 ms (ce qui correspond à 5 secondes). Sinon, si le temps nécessaire est insuffisant (' TCMR < Tcmr), aucun test n'est mis en oeuvre (429).
Dans des variantes, on pourra également rajouter une condition supplémentaire:
• Si la tendance d'évolution du débit est stable avec une tendance positive par rapport à l'historique de débit. On pourra par exemple utiliser une simple régression linéaire sur la bande passante estimée en fonction du temps d'arrivée des paquets sur une période de 500 ms pour calculer une pente (voir l'estimation de la pente décrite précédemment ou les variantes associées). Si la pente dépasse un seuil positif ou nul (par exemple 0), on pourra commencer un test par redondance pour tester le canal. Sinon, dans le cas où la une pente est négative, aucun test n'est mis en oeuvre (429).
Si un test d'augmentation de débit ("burst") est à activer (O en 422), alors, on définit les paramètres de la redondance à appliquer en 423. On vérifie:
• Si le codeur n'a pas de redondance en cours ( Nburst < 0; Nburst représentant le compteur de trame avec redondance) lors du codage de la trame courante. Si c'est le cas, alors on fixe les paramètres suivants: l'offset de la redondance à Kburst (par exemple à 2) et on initialise le compteur de trames avec redondance à Nburst = Lburst + Khurst avec par exemple Lburst à 100.
• Si le codeur est en cours de redondance ( Nburst ³ 0) lors du codage de la trame courante, alors, on vérifie:
■ Si on a atteint la fin de la redondance appliquée actuelle (Nburst = 0).
Dans ce cas, on fixe Kburst = -1 et on réinitialise TCMR -Q·
■ Sinon : on décrémente le compteur de trames avec redondance avec burst — burst — 1
En E427, l'émetteur vérifie si un CMR doit être transporté dans le paquet associé à la trame courante à coder. Si c'est le cas, les données du CMR dans la structure "BW_Info" sont extraites pour codage ultérieur du CMR.
L'émetteur crée ensuite l'entête du payload RTP courant, si les champs CMR et ToC sont à insérer dans le paquet courant. Pour le champ CMR, on renvoie le lecteur aux tableaux A.2 et A.3 de l'annexe A de la spécification 3GPP TS 26.445 pour la construction et le codage du champ CMR pour le codée EVS à partir des informations sur la requête CMR (débit, bande codée...) à coder. Si un champ CMR doit être envoyé mais l'entrée "updated" de la structure "BW_Info" a la valeur "faux", on utilisera le code NO_REQ qui correspond à T= l l l et D= ll l l (en binaire). De façon similaire, le codage du champ ToC est décrit dans la figure A.4 et les tableaux A.4 et A.5 de l'annexe A de TS 26.445. Selon l'invention, si la redondance 100% est utilisée dans le paquet courant, le champ ToC décrira à la fois le débit de la trame courante, le débit de la trame redondante et l'offset de redondance Kburst (en utilisant le nombre adéquat de ToC associés à NO_DATA). On rappelle que des exemples de structure de trames redondantes sont donnés au chapitre 10 de la spécification 3GPP TS 26.114 et la construction du champ ToC suit les principes donnés dans cette spécification pour les codées AMR, AMR-WB et EVS.
La trame courante est codée en 427 et ajoutée aux données du paquet.
Si la redondance est activée (O en 422), la trame codée redondante correspondant à l'offset Kburst (mémorisée dans une file ou une autre structure de données) est aussi ajoutée aux données du paquet courant pour être transmise en 428.
Le paquet ainsi formée avec les entêtes (éventuelles) et données codées est transmis (428) en utilisant les informations relative à la taille de la charge utile RTP et le nombre de trames codées depuis la réception du dernier CMR est incrémenté de 1 ( TCMR <- TCMR + 1). La trame codée courante est mémorisée dans une file pour une éventuelle utilisation ultérieure comme trame redondante.
On notera qu'il n'est pas toujours possible de doubler le débit de codage, si la session SDP (avec le paramètre b=AS) ou les paramètres de qualité de service (GBR et MBR sur réseau mobile de type VoLTE) limitent le débit maximal utilisable par le codée.
Dans des variantes de l'invention, on prendra par exemple en compte la définition d'un paramètre SDP de type b=AS limitant le débit maximal utilisable par le codée. Par exemple dans le cas du codée EVS SWB, on peut avoir un paramètre b=AS limitant le débit à 24.4 kbit/s (en transmission d'une trame unique de 20 ms). Dans ce cas, selon l'invention, on pourra limiter l'utilisation de la redondance de deux façons :
• si le réseau ne rejette pas les paquets sur la base du débit instantané (par exemple un débit supérieur à 24.4 kbit/s) mais en utilisant une moyenne glissante du débit sur une fenêtre temporelle (par exemple d'une durée de 2 secondes comme indiqué à la section 7.5.5.1 de la spécification 3GPP TS 26.114), on pourra garder la réalisation d'une transmission alternée de paquets avec ou sans redondance, c'est-à-dire utiliser une transmission redondante intermittente pour le test d'augmentation de débit. La fréquence de transmission des paquets redondants est alors adaptée à cette contrainte de débit maximum. On détaille plus loin une variante du premier mode de réalisation pour ce cas.
• si aucun paquet ne peut dépasser une taille limite correspondant au débit maximal (par exemple une taille correspondante à 24.4 kbit/s), on pourra tester par exemple 2x9.6 kbit/s mais pas 2x13.2 kbit/s et on pourra passer ainsi aux débits de 13.2 ou 16.4 kbit/s qui sont compris entre 9.6 et 2x9.6 kbit/s; par contre il sera difficile de tester le passage à 24.4 kbit/s, à moins d'alterner un codage à 9.6 et un codage à 13.2 et d'associer une trame codée et une trame redondante pour un débit d'environ 9.6+13.2 kbit/s. Dans tous les cas, cette variante implique qu'avant d'appliquer la redondance, une diminution du débit à un débit discret inférieur doit être potentiellement effectuée (par exemple pour tester si l'on peut passer de 13.2 à 16.4 ou de 16.4 à 24.4 kbit/s). On utilisera un débit inférieur (par exemple 9.6 kbit/s) au débit actuel (par exemple 13.2 ou 16.4 kbit/s). En effet il ne serait pas possible d'utiliser 2x13.2 kbit/s, car cela dépasserait le débit de 24.4 kbit/s et seuls les cas 2x9.6 kbit/s et 9.6+13.2 kbit/s seront autorisés.
Dans des variantes de l'invention selon le premier mode de réalisation, l'activation de la redondance pourra n'être autorisée que lors des périodes de signal actif pour minimiser les impacts de l'augmentation de débit.
On a décrit précédemment un test d'augmentation de débit avec une redondance 100%, c'est-à-dire une redondance pour chaque paquet transmis pendant un nombre de trame déterminé ( Lburst ). Dans des variantes de réalisation, comme pour le deuxième mode de réalisation décrit ultérieurement, la redondance ne sera activée que de façon intermittente. Par abus de langage, on appellera ici "fréquence" de redondance la période avec laquelle un paquet redondant est utilisé - ainsi une fréquence de x signifie qu'une trame redondante est insérée tous les x paquets.
Plutôt que de doubler (approximativement) le débit de codage, la redondance est utilisée par exemple tous les 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation relative de débit fractionnaire, afin de tester (en moyenne) le passage au débit discret immédiatement supérieur et non un débit doublé.
Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de (freq+ l)/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq= l, 1.5x9.6 (approx. 14.4) si freq=2, 4/3x9.6 (approx. 12.8) si freq=3.
L'offset de redondance est fixé à la même valeur que le paramètre de fréquence (freq) pour que la redondance puisse être exploitée.
Cet autre paramètre définissant la redondance, pourra être déterminé à l'étape 423 de la figure 4c en fonction d'information du débit actuel et du débit immédiatement supérieur. Par exemple, si la gamme de débit 9.6 à 24.4 kbit/s est utilisable dans une session avec le codée EVS en mode Super-Wideband, on pourra utiliser: - à partir d'un débit de 9.6 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 9.6 kbit/s tous les 2 paquets (pour arriver à un débit moyen sur le canal de près de 14.4 kbit/s) ou tous les 3 paquets (approximativement 12.8 kbit/s)
- à partir d'un débit de 13.2 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 13.2 kbit/s tous les 3 paquets (approx. 17.6 kbit/s) ou tous les 4 paquets (approx.16.5 kbit/s)
- à partir d'un débit de 16.4 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 16.4 kbit/s tous les 2 paquets (approx. 24.6 kbit/s)
La fréquence d'envoi de la redondance est donc adaptative, en fonction du débit actuel. Elle est de 2 ou 3 à 9.6 kbit/s, 3 ou 4 à 13.2 kbit/s, 2 à 16.4 kbit/s.
L'offset de redondance sera de façon privilégié défini comme étant égal à la fréquence d'envoi des paquets redondant pour compenser d'éventuelles pertes des paquets plus volumineux. Dans des variantes il sera possible d'utiliser un autre offset pour répéter par exemple la trame qui suit immédiatement le paquet avec redondance.
D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant DO et du débit discret DI immédiatement supérieur pour un codée donné, comme la valeur entière la plus proche de 1/(D1/D0-1).
A titre d'exemple, on considère les cas suivants (Tableau 1) qui seront utilisés de façon privilégiée dans cette variante du premier mode de réalisation:
Tableau 1
On présente ensuite un deuxième mode de réalisation où l'émetteur et le récepteur agissent encore de manière coordonnée mais où cette fois-ci le récepteur envoie une requête explicite d'activation de redondance 100% pour tester une augmentation de débit, par le biais d'une requête CMR étendue. On suppose dans cette description un débit maximal de 24.4 kbit/s et une valeur de b=AS correspondante à ce débit maximal.
Dans ce mode de réalisation, les codes CMR existants du codée EVS (comme définis dans le tableau A.3 de la spécification 3GPP TS 26.445) sont utilisés pour envoyer une requête vers un débit de codage donné, lorsqu'il s'agit de baisser ou d'augmenter le débit en fonction de la bande passante disponible estimée. Cependant, un CMR non classique, dit CMR étendu est nécessaire pour envoyer une requête d'activation de redondance, car les codes CMR existants du codée EVS ne permettent qu'une adaptation en débit, bande audio et le contrôle d'un mode spécial de redondance partiel à 13.2 kbit/s (appelé « channel-aware mode »). On suppose que la session SDP inclut un paramètre supplémentaire appelé sans perte de généralité "adapt" pour signaler et autoriser l'utilisation d'un tel CMR étendu, et que les deux terminaux sont compatibles avec le paramètre SDP "adapt". Pour indiquer l'activation d'une étape de test d'augmentation de débit par une transmission de paquets redondants, par exemple, une redondance 100%, dans le cas du codée EVS, on utilise selon ce mode de réalisation, des codes CMR qui sont libres, laissés pour un usage futur ( "for future use") ou réservé ("reserved") et qui ne sont pour l'instant pas utilisés dans les spécifications du codée EVS.
A titre d'exemple, on considère les codes suivants (Tableau 2):
Tableau 2
où la redondance 100% est activée par l'émetteur de façon intermittente tous les 1, 2, ou 3 paquets (selon la fréquence d'envoi) pour augmenter le débit.
Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de (freq+l)/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq = l, 1.5x9.6 (approx. 14.4) si freq=2, 4/3x9.6 (approx. 12.8) si freq=3.
L'offset est fixé à la même valeur que la fréquence (freq) pour que la redondance puisse être exploitée. Dans des variantes, une autre convention pourra être définie pour fixer la valeur d'offset.
On ne détaille pas ici les détails de construction ou d'extraction de CMR selon le tableau 2. Cependant on suppose que la structure "CMR_Req" contiennent un champ appelé "burst_uplink" qui est mis à "1", "2" ou "3" lorsque des codes CMR étendus selon le tableau 2 sont utilisés, sinon sa valeur est mise à "-1". Ainsi en combinant l'entrée "requested_bitrate" et cette entrée "burst_uplink" il est possible de signaler complètement le type de requête à envoyer ou de requête reçue.
Une caractéristique importante de ce deuxième mode de réalisation par rapport à l'utilisation classique de redondance 100% est que la redondance est de façon privilégiée intermittente: plutôt que de doubler (approximativement) le débit de codage, la redondance est utilisée de façon adaptative par exemple tous les 1, 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation de débit fractionnaire, afin de tester (en moyenne) le passage au débit discret immédiatement supérieur et non un débit doublé. D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant D0 et du débit discret DI immédiatement supérieur pour un codée donné, comme la valeur entière la plus proche de 1/(D1/D0-1).
Dans le cas où le débit pic instantané ne peut pas dépasser le débit maximal autorisé dans la session (par exemple 24.4 kbit/s), on n'utilisera que des requêtes associées à 9.6 kbit/s avec différentes valeurs de fréquences (freq= l, 2 ou 3), sachant qu'il sera difficile dans ce cas de tester un débit proche de 24.4 kbit/s car la fréquence freq= l donne un débit autour de 19.2 kbit/s. Sinon on pourra également autoriser les requêtes associées au débit de 13.2 kbtit/s, ce qui permet de tester des débits d'approximativement (freq+ l)/freq x 13.2, soit 2x13.2 (approx. 26.4) si freq= l, 1.5x13.2 (approx. 19.8) si freq=2, 4/3x13.2 (approx. 17.6) si freq=3.
A partir de la bande passante estimée - en instantané ou sur un horizon de passé donné par l'historique - et en utilisant potentiellement des informations supplémentaires comme le taux de pertes de paquets mesuré en réception (où la bande passante estimée sera multiplié par un facteur < 1 comme 0,9 dès que le taux est par exemple > 10%), une requête d'adaptation de débit est déterminée et encodée en un code CMR (bloc 302 et 352 de la figure 3). Cette requête CMR est rajoutée par l'émetteur local dans le prochain paquet à transmettre.
On définit selon l'invention trois types de décisions de requête d'adaptation à envoyer pour l'adaptation de débit :
• décision "SET_RATE" : on envoie dans ce cas un CMR qui indique un débit de codage qui correspond à la bande passante estimée si le débit actuel n'est pas dans un intervalle autour de cette bande passante estimée ;
• décision "NO_REQ" : on garde le débit actuel si le débit à utiliser reste inchangé - dans ce cas on peut envoyer un CMR indiquant le débit actuel ;
• décision "USE_RED": on envoie un CMR indiquant qu'il faut activer la redondance 100% à l'émission - dans un mode de réalisation privilégié, la redondance est utilisée de façon adaptative - avec un offset adaptatif lié au débit de codage - pour tester le passage au débit immédiatement supérieur au débit actuel (avec une fréquence d'envoi variable), dans des variantes on pourra envisager d'activer la redondance pour un usage en continu - avec freq= l et offset = 1 - jusqu'à ce qu'on détecte des problèmes de qualité. Cela permet une remontée rapide du débit mais en général on préférera une remontée progressive par paliers pour tester les débits supérieurs un par un.
Pour les codées AMR et AMR-WB qui fonctionnent avec un feedback inband par CMR, la signification du CMR NO_REQ est différente de celle d'EVS, NO_REQ indique le débit maximal autorisé. Dans des variantes utilisant ces codées, on remplacera donc la décision NO_REQ par une décision SET_RATE pour indiquer le débit courant. Dans des variantes de l'invention utilisant EVS on pourra de la même façon remplacer la décision NO_REQ par une décision SET_RATE pour indiquer le débit courant.
Selon ce deuxième mode de réalisation, des codes CMR réservés sont utilisés, ce qui justifie la notation de CMR étendu (Ext. CMR) dans les blocs 307 et 357 de la figure 3. Les codes étendus de CMR servent à indiquer une requête d'adaptation pour augmenter le débit de codage, cette requête indique à l'émetteur distant de tester un débit supérieur à ce débit donné dans la requête - dans ce cas l'émetteur activera par transmission de paquets redondants, une transmission à ce débit donné avec redondance 100%.
Cette requête suppose une utilisation de redondance côté émetteur. Dans un mode de réalisation simplifié, l'émetteur pourra exécuter la requête issue du CMR comme dans le premier mode de réalisation de l'invention, en vérifiant que l'entrée "updated' est à "vrai" dans la structure "CMR_Req" et en appliquant les paramètres d'adaptation contenus dans "CMR_Req"; après récupération des paramètres, la valeur de "updated" est remise à "faux". Dans un mode de réalisation privilégié, on laissera à l'émetteur suffisamment de flexibilité pour exécuter la requête d'activation de redondance en fonction du signal en cours de codage. Comme expliqué plus loin l'augmentation de débit peut résulter en une congestion, avec des pertes de paquets ou une augmentation de la gigue, il est donc important, quand la bande passante disponible n'est pas connue et testée en aveugle (pour estimer le "bottleneck" dans le sens descendant) de ne pas dépasser outre mesure cette limite sur le canal; par ailleurs l'impact des pertes et de la gigue est différent selon les types de trames codées, pour les parties inactives ou les parties les moins sensibles de la parole active, on peut plus facilement tolérer ces dégradations.
Pour ce deuxième mode de réalisation, la figure 5a reprend du premier mode de réalisation les étapes d'extraction effectuées au récepteur. Ainsi, à la réception d'un paquet en 501, deux informations sont extraites au récepteur: • des informations de transmission du paquet actuel permettant l'estimation de la bande passante disponible (en 502) selon une des méthodes d'estimation précédemment décrites. L'extraction de ces informations est suivie par les étapes X décrites en référence à la figure 5b ;
• des informations sur le type d'adaptation demandé à partir de la requête CMR envoyée par l'autre bout de la communication (en 503).
La différence principale avec la figure 4a concerne le fait que la requête CMR peut correspondre à un CMR étendu alors qu'à la figure 4a on suppose une requête CMR "classique"; de plus les étapes X incluent également la possibilité de décider d'envoyer une requête étendue pour activer la redondance en utilisant l'entrée "burst_uplink".
La figure 5b détaille les étapes X mises en oeuvre par le dispositif récepteur après extractions des informations sur le paquet actuel (502).
De la même façon que pour le premier mode de réalisation, une estimation de la bande passante est faite selon l'une des méthodes précédemment décrite (en 511). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 512) comme décrite précédemment pour déterminer s'il faut changer le débit de réception actuel et s'il est possible de passer d'un débit discret à un autre.
Si le débit déterminé selon la bande passante estimée dans le dernier paquet reçu est différent du débit actuel (O en 513), on prend la décision « SET_RATE », de changement de débit selon ce nouveau débit. Une requête classique de changement de débit à un débit discret correspondant est définie à l'étape 514 ; les données associées sont écrites dans la structure partagée "BWJnfo", pour que l'émetteur puisse ensuite coder la requête correspondance avec la trame à envoyer.
Dans le cas où le nouveau débit est identique au débit actuel, alors une étape de vérification de conditions d'application de test est effectuée en 516.
Cette étape de vérification 516 vérifie l'historique d'estimation de bande passante et mesure ainsi une tendance de variation de la bande passante estimée. Si cette tendance est positive (O à 516), c'est-à-dire si la bande passante estimée tend à augmenter, alors une décision « USE_RED » peut être prise et l'étape 517 est alors mise en oeuvre.
Dans le cas contraire (N à 516), si la tendance est négative, alors il n'y a pas d'émission de requête, la décision « NO_REQ » est prise et les données associées au CMR sont écrites dans la structure partagée "BWJnfo".
Pour mesurer la tendance de variation, on pourra par exemple utiliser une simple régression linéaire sur la bande passante estimée en fonction du temps d'arrivée des paquets sur une période de 500 ms pour calculer une pente, comme décrit précédemment.
Le temps depuis lequel cette décision « NO-REQ » reste sélectionnée peut être mesuré pour décider si un test d'augmentation de débit doit être activé ou non. Si ce temps écoulé est inférieur à un seuil (par exemple 500 ms), alors une décision « NO_REQ » est prise (N à 516). Le mode « NO-REQ » n'a pas été suffisamment long. Dans ce cas, on enverra typiquement aucune requête (pas de CMR) ou un CMR indiquant NO_REQ en 519 - dans ce dernier les données associées au CMR NO_REQ sont écrites dans la structure partagée "BWJnfo".
Dans des variantes, on pourra réutiliser les critères de déclenchement (d'activation) du test d'augmentation de débit du premier mode de réalisation.
Dans des variantes, la décision NO_REQ sera remplacée par une décision SET_RATE au débit actuel, de façon équivalente. On notera que pour les codées AMR et AMR-WB le CMR est systématiquement présent dans chaque paquet, et on pourra remplacer le cas NO_REQ par le débit actuel.
A l'inverse (O à 516), lorsque le temps écoulé est supérieur au seuil, la décision « USE_RED » est prise pour demander un test d'augmentation du débit. Dans ce cas, à l'étape 517, une requête CMR étendue est préparée, en écrivant les données associées au CMR étendu dans la structure partagée "BWJnfo.
La figure 5c décrit le fonctionnement de l'émetteur à la réception d'une requête CMR (normale ou étendue, autre que NO_REQ). On ne reprend pas ici les étapes restées identiques à l'émetteur en rapport à la figure 4c par souci de simplification.
Deux cas possibles se présentent lors de l'étape de vérification si un champ CMR a été reçu. Ainsi, si le champ CMR contient une requête d'adaptation du débit classique ou une requête CMR étendue, les paramètres de codage et d'émission sont fixés comme dans le premier mode de réalisation. Cependant, on pourra laisser l'émetteur décider du moment pour activer la redondance.
En rapport avec la figure 5c, à l'étape 521, on vérifie si un CMR classique de changement de débit a été reçu ("updated" à "vrai" et "burst_uplink"=-l) et si une étape de test par transmission de paquets de redondance est en cours (Nburst ³ 0). Dans la positive (O en 521), on arrête l'étape de test et on désactive la redondance en 522 comme décrit précédemment dans le premier mode de réalisation.
S'il n'y a pas d'étape de test en cours (N en 521) - si Nburst < 0 -, alors l'étape 523 est mise en oeuvre.
A l'étape 523, on vérifie si une requête CMR étendu a été reçue ("updated" à "vrai" et "burst_uplink>0" dans la structure "CMR_Req"). Dans la positive (O en 523), l'émetteur met en oeuvre une étape de test d'augmentation de débit par la transmission de paquets redondants en 524 en fonction des informations contenues dans la structure "CMR_Req". On fixe également le débit pour coder la prochaine trame en fonction du CMR reçu (en 525).
Dans des variantes l'algorithme ci-dessus peut être complété pour utiliser également le taux de perte de paquets. Cela rajoute des conditions supplémentaires pour en particulier baisser le débit en cas de pertes significatives (> = 10%) et/ou basculer sur un mode plus robuste (comme le channel-aware mode) s'il est inférieur ou égal au débit actuel, ou éviter la décision USE_RED en cas de pertes >= 10%.
Dans des variantes, on pourra utiliser une redondance partielle comme expliqué ci- dessus au lieu de la redondance 100% et on pourra également utiliser une redondance plus élevée, non limitée à 100% , par exemple une redondance à 200 ou 300%.
Dans des variantes, on pourra aussi utiliser des codées audio ou vidéo qui ne disposent pas du mécanisme de signalisation CMR « dans la bande » (« inband » en anglais) tel que défini précédemment, dans ce cas on pourra utiliser des paquets RTCP pour indiquer des requêtes équivalentes au CMR utilisé dans les modes de réalisation de l'invention.
La figure 6 illustre un exemple matériel d'un terminal de communication TA comportant un dispositif récepteur et un dispositif émetteur apte à mettre en oeuvre les procédés d'adaptation de débit et de détermination d'une requête d'adaptation selon les différents modes de réalisation de l'invention.
Le terminal TA comporte un espace de stockage 11, par exemple une mémoire MEM, une unité de traitement 10 comportant un processeur P, piloté par un programme informatique PG, stocké dans la mémoire 11 et mettant en oeuvre les étapes du procédé de d'adaptation de débit et/ou du procédé de détermination d'une requête d'adaptation de débit au sens de l'invention, et notamment l'étape de test d'augmentation du débit de codage mis en oeuvre par un dispositif émetteur par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis , lorsque ces instructions sont exécutées par le processeur P.
Typiquement, la description des figures 4a à 4c et des figures 5a à 5c reprend les étapes des algorithmes de tels programmes informatiques.
A l'initialisation, les instructions de code du programme PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur P de l'unité de traitement 10. Les instructions de programme peuvent être mémorisées sur un support de stockage tel qu'une mémoire flash, un disque dur ou tout autre support de stockage non-transitoire.
Le terminal TA comporte un module de communication 12 apte à recevoir les paquets voix d'un réseau IP et à transmettre des paquets voix vers le réseau IP avec une redondance pour tester une augmentation de débit selon l'invention.
Le terminal comprend un dispositif émetteur comportant une unité de transmission de paquets apte à mettre en oeuvre une étape de test d'augmentation du débit de codage par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis. Le terminal comprend également un dispositif récepteur qui selon un mode de réalisation, comporte un module d'estimation apte à estimer une bande passante disponible et un module de construction et de transmission d'une requête d'adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en oeuvre d'une étape de test d'augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
Ces modules sont tels que décrits en référence à la figure 3.
Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous- programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.)
Le terminal est par exemple un téléphone, un téléphone intelligent, une tablette, un ordinateur, une passerelle résidentielle ou un objet connecté.
ANNEXE 1 :
EVS_D(0 à 8) = (9600, 13200, 16400, 24400, 32000, 48000, 64000, 96000, 12800)
Pour i=0 à 8:
Si EVS_D(i) > B-(EVS_D(i+ l)-EVS_D(i))/2:
Sortir de la boucle "Pour"
Fin Si
i = i+1
Fin Pour
Si i ==9: D = EVS_D(i-l)
Sinon D = EVS_D(i)

Claims

REVENDICATIONS
1. Procédé d'adaptation d'un débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu'il comporte une étape de test d'augmentation du débit de codage au dispositif émetteur par la transmission (428) d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi (423).
2. Procédé selon la revendication 1, dans lequel l'étape de test est mise en oeuvre tant qu'aucune requête d'adaptation de débit n'est reçue d'un dispositif récepteur.
3. Procédé selon l'une des revendications 1 à 2, dans lequel l'étape de test est mise en oeuvre après un changement de débit au débit discret inférieur.
4. Procédé selon l'une des revendications 1 à 3, dans lequel l'étape de test est mise en oeuvre lorsqu'une temporisation a atteint un seuil depuis la dernière requête d'adaptation reçue d'un dispositif récepteur.
5. Procédé selon la revendication 4, dans lequel la temporisation pour déclencher le test d'augmentation est adaptée en fonction d'une information de bande passante disponible estimée au dispositif récepteur.
6. Procédé selon l'une des revendications 1 à 5, dans lequel l'étape de test est mise en oeuvre en fonction d'une information d'évolution du débit de codage obtenue.
7. Procédé selon la revendication 6, dans lequel l'information d'évolution du débit de codage est obtenue à partir d'un historique de bande passante disponible estimée au dispositif récepteur.
8. Procédé selon la revendication 1, dans lequel l'étape de test est mise en oeuvre après réception d'une requête d'adaptation reçue d'un dispositif récepteur et comportant une demande de transmission de paquets redondants selon des paramètres de transmission choisis.
9. Procédé selon la revendication 8, dans lequel la requête d'adaptation est déterminée au dispositif récepteur, en fonction d'une information d'évolution d'une bande passante disponible estimée.
10. Procédé de détermination d'une requête d'adaptation de débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteurs et des dispositifs récepteurs de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu'il comporte une étape d'estimation d'une bande passante disponible (511) pour un dispositif récepteur et de construction d'une requête d'adaptation (517) à transmettre à un dispositif émetteur et comportant une demande de mise en oeuvre d'une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
11. Dispositif émetteur d'un terminal de communication apte à mettre en oeuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu'il comporte une unité de transmission de paquets (301, 351) apte à mettre en oeuvre une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
12. Dispositif récepteur d'un terminal de communication apte à mettre en oeuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu'il comporte un module d'estimation (304, 354) apte à estimer une bande passante disponible et un module de construction (302, 352) et de transmission d'une requête d'adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en oeuvre d'une étape de test d'augmentation du débit de codage par la transmission d'une trame courante et d'au moins une recopie d'une trame précédente selon un offset choisi.
13. Terminal de communication comportant un dispositif émetteur selon la revendication 11 et/ou un dispositif récepteur selon la revendication 12.
14. Programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé d'adaptation selon l'une des revendications 1 à 10 et /ou des étapes du procédé de détermination d'une requête selon la revendication 10, lorsque ces instructions sont exécutées par un processeur.
15. Support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l'exécution du procédé d'adaptation selon l'une des revendications 1 à 10 et /ou des étapes du procédé de détermination d'une requête selon la revendication 10.
EP19742839.4A 2018-06-08 2019-06-03 Adaptation de débit d'une session de communication en voix sur ip Pending EP3804243A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1855048A FR3082386A1 (fr) 2018-06-08 2018-06-08 Adaptation de debit d'une session de communication en voix sur ip
PCT/FR2019/051301 WO2019234338A1 (fr) 2018-06-08 2019-06-03 Adaptation de débit d'une session de communication en voix sur ip

Publications (1)

Publication Number Publication Date
EP3804243A1 true EP3804243A1 (fr) 2021-04-14

Family

ID=63638002

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19742839.4A Pending EP3804243A1 (fr) 2018-06-08 2019-06-03 Adaptation de débit d'une session de communication en voix sur ip

Country Status (4)

Country Link
US (1) US11349898B2 (fr)
EP (1) EP3804243A1 (fr)
FR (1) FR3082386A1 (fr)
WO (1) WO2019234338A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117118952A (zh) * 2018-11-02 2023-11-24 苹果公司 发信号传送多媒体电话会话的编解码器模式通知
US11824737B2 (en) * 2019-09-09 2023-11-21 Apple Inc. Per-packet type packet loss management
CN113747202B (zh) * 2021-08-05 2023-09-15 杭州网易智企科技有限公司 一种通过带宽估计发送数据的方法、装置、设备及介质
CN117223286A (zh) * 2022-03-30 2023-12-12 吉欧平台有限公司 限制增强型语音业务（evs）的比特率的系统和方法
US20230318980A1 (en) * 2022-04-04 2023-10-05 Google Llc Congestion control for low-latency interactive video streaming

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BRPI0715131B1 (pt) * 2006-08-21 2019-11-05 Ericsson Telefon Ab L M método e arranjo para adaptar a transmissão de mídia codificada em uma rede comutada por pacote para diferentes condições de operação
US20100121974A1 (en) * 2008-11-11 2010-05-13 Einarsson Torbjoem Stepwise probing for adaptive streaming in a packet communication network
WO2010111261A1 (fr) * 2009-03-23 2010-09-30 Azuki Systems, Inc. Procédé et système d'adaptation dynamique de débit de lecture vidéo en transit
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US20130195119A1 (en) * 2011-10-14 2013-08-01 Qualcomm Incorporated Feedback channel for wireless display devices
WO2017052436A1 (fr) * 2015-09-25 2017-03-30 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et nœud de réseau d'interfonctionnement pour permettre une adaptation de débit binaire dans une diffusion en continu de contenu multimédia
US10652594B2 (en) * 2016-07-07 2020-05-12 Time Warner Cable Enterprises Llc Apparatus and methods for presentation of key frames in encrypted content
EP3625945B1 (fr) * 2017-06-09 2021-09-15 Huawei Technologies Co., Ltd. Dispositif de communication émetteur et procédé de transmission de données vidéo

Also Published As

Publication number Publication date
FR3082386A1 (fr) 2019-12-13
US11349898B2 (en) 2022-05-31
US20210258363A1 (en) 2021-08-19
WO2019234338A1 (fr) 2019-12-12

Similar Documents

Publication Publication Date Title
EP3804243A1 (fr) Adaptation de débit d&#39;une session de communication en voix sur ip
US10965603B2 (en) Bandwidth management
EP3692696B1 (fr) Signalisation d&#39;une requête d&#39;adaptation d&#39;une session de communication en voix sur ip
JP5528811B2 (ja) 効率的なメディアの扱いのための受信機の動作及び実装
FR2908576A1 (fr) Procede,dispositif et application logicielle d&#39;ordonnancement d&#39;une transmission de paquets d&#39;un flux de donnees
US11916798B2 (en) Estimating network bandwidth using probe packets
EP2793443B1 (fr) Procédé, dispositif et système de détection de problème de qualité de service
Herrero Integrating HEC with circuit breakers and multipath RTP to improve RTC media quality
FR3030174A1 (fr) Procede de controle d&#39;une communication telephonique initiee par un terminal connecte a un reseau de communication
FR2946820A1 (fr) Procede de transmission de donnees et dispositif associe.
EP1172958A1 (fr) Système de communication, émetteur, mèthode de protection contre des erreurs de transmission
FR2804813A1 (fr) Procede de codage facilitant la restitution sonore des signaux de parole numerises transmis a un terminal d&#39;abonne lors d&#39;une communication telephonique par transmission de paquets et equipement mettant en oeuvre ce procede
EP1427154A1 (fr) Procédé de contrôle d&#39;une mémoire tampon de paquets de données, et dispositif correspondant
Assem Assessing and improving the VVoIP call quality
FR2941110A1 (fr) Procede et dispositif de prediction d&#39;un etat de pertes d&#39;un reseau de communication
Herrero Analytical model and comparative evaluation of application layer loss in the context of media encapsulation in wireless RTC
Balan et al. An experimental evaluation of voice-over-ip quality over the datagram congestion control protocol
Bhattacharya Flow control of real-time unicast multimedia applications in best-effort networks
WO2009136114A1 (fr) Négociation optimisée de ressources de codage entre clients de communication
Sivarajah Media Transport over the Internet
FR2979505A1 (fr) Procede d&#39;insertion d&#39;un equipement intermediaire permettant le controle a distance de la qualite d&#39;une communication
Osuagwu Improving multimedia transmission through enhanced multimedia devices
FR3037461A1 (fr) Procede d&#39; evaluation de la qualite d&#39; une communication de voix sur ip mobile
KAZEMITABAR VOIP WITH ADAPTIVE RATE IN MULTI-TRANSMISSION RATE WIRELESS LANS
WO2007101962A1 (fr) Mécanisme de régulation multicouches du débit d&#39;un flux de données tcp dans un réseau haut débit ethernet full duplex

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210104

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20221130