CN109219078B - Voice packet loss processing method and device - Google Patents

Voice packet loss processing method and device Download PDF

Info

Publication number
CN109219078B
CN109219078B CN201710538087.1A CN201710538087A CN109219078B CN 109219078 B CN109219078 B CN 109219078B CN 201710538087 A CN201710538087 A CN 201710538087A CN 109219078 B CN109219078 B CN 109219078B
Authority
CN
China
Prior art keywords
packet
sdu
receiving end
packet loss
head
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.)
Active
Application number
CN201710538087.1A
Other languages
Chinese (zh)
Other versions
CN109219078A (en
Inventor
程岳
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.)
Datang Mobile Communications Equipment Co Ltd
Original Assignee
Datang Mobile Communications Equipment Co Ltd
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 Datang Mobile Communications Equipment Co Ltd filed Critical Datang Mobile Communications Equipment Co Ltd
Priority to CN201710538087.1A priority Critical patent/CN109219078B/en
Publication of CN109219078A publication Critical patent/CN109219078A/en
Application granted granted Critical
Publication of CN109219078B publication Critical patent/CN109219078B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • 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/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage

Abstract

The embodiment of the invention relates to a voice packet loss processing method and a device, wherein in the method, when a packet loss event is determined to occur and the packet loss event can influence the normal analysis of a receiving end, head node SDU in a queue to be sent is compressed again, so that the compressed message head carries indication information which can enable the receiving end to know the timestamp of the head node SDU packet, the head node SDU packet is sent to the receiving end, and then other SDU packets in the queue are compressed again according to ROHC after the sending end is updated and sent to the receiving end. Therefore, the receiving end can update the ROHC context of the receiving end according to the indication information carried by the head node SDU, and can correctly analyze the next received SDU, so that the condition that more data packets cannot be correctly analyzed due to continuous transmission of the data packets in the queue in packet loss feedback can not occur, the further deterioration of the packet loss rate can be effectively prevented, meanwhile, the receiving end can be prevented from causing meaningless state migration due to decompression failure, and the whole packet loss processing process is enabled to be simple and efficient.

Description

Voice packet loss processing method and device
Technical Field
The invention relates to the technical field of communication, in particular to a voice packet loss processing method and device.
Background
In L TE mobile communication network, VO L TE (Voice Over L TE, Voice service based on L TE) is an end-to-end Voice solution under all IP conditions, Voice packets have the characteristics of periodic arrival and relatively fixed packet size, and Voice is compressed and encoded by Adaptive Multi-Rate (AMR) and then encapsulated into IP packet transmission, for example, wideband Voice packets with a maximum Rate of 23.85Kbps are 61 bytes, but the Header RTP/UDP/IPv6 in AMR reaches 60 bytes, so the actual utilization Rate of air bandwidth is only about 50%, the size of Voice silence packets is only 7 bytes, but the Header reaches 60 bytes, the bandwidth utilization Rate is lower to 10%, while ROHC (Robust Header Compression, protocol 3095) can compress the headers (Header RTP/UDP/IPv6 or IPv4) to the extent of 1 to 3 bytes, and more than 90% in general.
VO L TE voice data packet is transmitted in an UM (UM) unacknowledged mode in an access network protocol, and when the quality of a wireless link is deteriorated, an air interface packet is lost or UE or a base station is regularly and actively lost due to high service load and incapability of scheduling in time, the ROHC context of a receiving end is different from that of a sending end due to the occurrence of packet loss, and the receiving end cannot know the correct time stamp TS corresponding to the received data packet, so that CRC failure occurs when the received data packet is decompressed.
However, in the process of making the invention, the inventor finds that: for the receiving end, when the verification fails, the status needs to be fed back to the transmitting end in a NACK manner and the status is returned. In this process, the receiving end still receives the SDU (service Data Unit, service Data Unit packet) that has entered the queue to be sent at the sending end, which results in continuous decompression failure and a large amount of Data packets being discarded. For the sending end, as NACK or SNACK fed back by the receiving end is received, a longer data packet type needs to be sent to synchronize the ROHC context of the receiving end, which results in a decrease in bandwidth utilization and a waste of air interface resources.
Disclosure of Invention
The embodiment of the invention provides a voice packet loss processing method and a voice packet loss processing device, which are used for solving the problems that in the prior art, a data packet which cannot be correctly decompressed is still received in the process of compression failure feedback of a receiving end, and an air interface resource is wasted because a transmitting end needs to transmit a longer data packet.
In a first aspect, an embodiment of the present invention provides a method for processing a voice packet loss, including:
when determining that a packet loss event of an SDU packet of a voice service data unit occurs and the packet loss event causes a receiving terminal to be incapable of correctly analyzing the received SDU packet, performing header compression again on a header SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol, so that an indication information for enabling the receiving terminal to acquire a timestamp of the header SDU packet is carried in a compressed packet header, and transmitting the header SDU packet to the receiving terminal;
and updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
Optionally, the determining that the packet loss event of the voice service data unit SDU includes: detecting at least one event occurrence of:
the media access control MAC layer fails to send the voice SDU;
the PDCP layer discards the SDU packet due to the overtime of the timer;
and receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
Optionally, determining that the packet loss event causes the receiving end to fail to correctly parse the received SDU packet includes:
if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the SDU packet successfully sent at the last timelastTime stamp TSlastAnd serial number SN corresponding to head node SDU packet of queue to be sentfirstTime stamp TSfirstKnowing that the timestamp proportional value TS _ Scale increases proportionally but the number of packet losses is greater than 2kIf so, determining that the packet loss event causes the receiving end not to correctly analyze the received SDU packet; k is a positive integer and is used for representing the least significant bit of the SN of the data packet type corresponding to the SDU packet which is successfully sent at the last time;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
according to SNlastAnd SNfirstObtaining SNfirstL sb;
according to the least significant bit L sb, selecting the SN capable of being carriedfirstThe data packet of (1);
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirst。
Optionally, determining that the packet loss event causes the receiving end to fail to correctly parse the received SDU packet includes:
if the packet loss process is knownMedium TS _ Stride has not changed and is according to SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining that the packet loss event causes the receiving end to be incapable of correctly analyzing the received SDU packet;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirstAnd TSfirst。
Determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet includes:
if the TS _ Stride changes in the packet loss process, determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the TSfirstAnd a changed TS _ Stride, wherein the TS isfirstIndicating the header SDU packet timestamp.
In a second aspect, an embodiment of the present invention further provides a device for processing a packet loss in a voice packet, including:
the first compression processing unit is used for carrying out head compression again on the head node SDU packets in the queue to be transmitted based on a robust packet head compression ROHC protocol when determining that a packet loss event of the voice service data unit SDU packets occurs and the packet loss event causes the receiving end not to correctly analyze the received SDU packets, so that indication information for enabling the receiving end to know the time stamps of the head node SDU packets is carried in the compressed message heads, and the head node SDU packets are transmitted to the receiving end;
and the second compression processing unit is used for updating the local ROHC compression context and carrying out head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
Optionally, the determining that the packet loss event of the voice service data unit SDU includes: detecting at least one event occurrence of:
the media access control MAC layer fails to send the voice SDU;
the PDCP layer discards the SDU packet due to the overtime of the timer;
and receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
Optionally, the first compression processing unit is configured to:
if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the SDU packet successfully sent at the last timelastTime stamp TSlastAnd serial number SN corresponding to head node SDU packet of queue to be sentfirstTime stamp TSfirstKnowing that the timestamp proportional value TS _ Scale increases proportionally but the number of packet losses is greater than 2kIf so, determining that the packet loss event causes the receiving end not to correctly analyze the received SDU packet; k is a positive integer and is used for representing the least significant bit of the SN of the data packet type corresponding to the SDU packet which is successfully sent at the last time;
and is also used for:
according to SNlastAnd SNfirstObtaining SNfirstL sb;
according to the least significant bit L sb, selecting the SN capable of being carriedfirstThe data packet of (1);
according to selected data packetType, based on ROHC protocol, head compressing again for said head node SDU packet, making compressed message head carry said SNfirst。
Optionally, the first compression processing unit is configured to:
if the TS _ Stride is not changed in the packet loss process, and according to the SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining that the packet loss event causes the receiving end to be incapable of correctly analyzing the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirstAnd TSfirst。
Optionally, the first compression processing unit is configured to:
if the TS _ Stride changes in the packet loss process, determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the TSfirstAnd a changed TS _ Stride, wherein the TS isfirstIndicating the header SDU packet timestamp.
In a third aspect, a further embodiment of the present invention provides a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method according to the first aspect when executing the program.
In a fourth aspect, a further embodiment of the invention provides a computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the steps of the method according to the first aspect.
The embodiment of the invention provides a voice packet loss processing method and a device, wherein in the method, when a packet loss event is determined to occur and the packet loss event can influence the normal analysis of a receiving end, head node SDU in a queue to be sent is compressed again, so that a compressed message header carries indication information capable of indicating a time stamp of the head node SDU packet, the head node SDU packet is sent to the receiving end, and then other SDU packets in the queue are compressed again according to ROHC after a sending end is updated and sent to the receiving end. Therefore, the receiving end can update the ROHC context of the receiving end according to the indication information carried by the head node SDU, and can correctly analyze the next received SDU, so that the condition that more data packets cannot be correctly analyzed due to continuous transmission of the data packets in the queue in packet loss feedback can not occur, the further deterioration of the packet loss rate can be effectively prevented, meanwhile, the receiving end can be prevented from causing meaningless state migration due to decompression failure, and the whole packet loss processing process is enabled to be simple and efficient.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a diagram of a VO L TE user plane protocol stack in the prior art;
FIG. 2 is a diagram illustrating a prior art UO-0 packet format based on the ROHC protocol;
FIG. 3 is a schematic diagram of a prior art UO-2 packet format based on the ROHC protocol;
fig. 4 is a flowchart of a voice packet loss processing method according to an embodiment of the present invention;
FIG. 5 is a schematic diagram illustrating spacing in the prior art;
fig. 6 is a schematic diagram of a UOR-2 extended format according to an embodiment of the present invention;
FIG. 7 is a diagram illustrating another UOR-2 extended format provided by an embodiment of the present invention;
fig. 8 is a flowchart of a complete voice packet loss processing method according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of an embodiment of a device for processing packet loss in voice according to the present invention;
FIG. 10 is a block diagram of an embodiment of a computer device provided by the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
For the understanding of the present invention, first, some prior art of the VO L TE user plane protocol stack and ROHC protocol related to the embodiment of the present invention will be described.
VO L TE user plane protocol stack
Fig. 1 shows a VO L TE user plane Protocol stack, at a core network or UE side, voice Data forms voice packets through different frames, frequencies, sampling rates and coding rates, and then is encapsulated into RTP (Real-Time Transport Protocol) packets, and finally forms IP packets to form VOIP, and transmits the VOIP to a radio access network side, the RTP voice payload is carried on PDCP (Packet Data Convergence Protocol) for transmission, and ROHC is used for enhanced transmission, the reason for ROHC is mainly on an air interface, because the payload of the voice Packet length is small (the longest is 61 bytes), the IP header length occupies a large part in a message (the RTP/UDP/IPv6 header is 60 bytes, and the RTP/UDP/IPv4 header is 40 bytes), therefore, in order to improve the bandwidth utilization, the ROHC algorithm needs to be started in radio transmission, the VO is generally sampled and compressed to the position of the RTP header at present, and the VO L TE service is IPv 6.
The wireless side PDCP protocol layer carries out header compression on the VOIP message, PDCP SN is added to the compressed message to form PDU, the PDU is sent to the R L C layer, the R L C layer adopts UM mode transmission, after the MAC obtains a dispatching opportunity, the PDU is sent to the opposite end, after the receiving end receives the message, the PDU is delivered to the receiving end PDCP layer, the PDU header is stripped off by the receiving end PDCP layer, and an ROHC decompression function is called for decompression.
(II) ROHC protocol
The RFC3095 protocol basic principle is to classify the header fields of the packets, because the adjacent packets have many parts that do not change during the transmission of the whole stream, such as IP addresses and UDP port numbers, and some header fields of the packets change regularly, such as the sequence number sn (sequence number) and the time stamp ts (time stamp) of the RTP header. The ROHC protocol establishes Context storage static and dynamic packet header fields for each data stream at both ends of the link, and the sending end notifies the solution sending end to acquire complete static and dynamic information by sending an IR (Initialization and Refresh) message, and the static part of the original message will not be sent any more in the subsequent message sending. The dynamic change field has a sequence number SN of the RTP header and a timestamp TS. For VOIP, the adjacent packet SN is incremented by 1 and the adjacent packet TS is incremented by the step value (TS _ Stride), so the TS can be directly inferred from the SN, for which the following proportional RTP timestamp coding is used:
TS＝TS_Scale*TS_Stride+TS_Offset (1)
wherein, TS _ Scale is a timestamp ratio value, TS _ Stride is a timestamp step value, and TS _ Offset is a timestamp Offset value.
The sending end sends the absolute value of several TS domains and TS _ STRIDE to the decompressor, the decompressor can calculate TS _ OFFSET, after the initialization process is completed, the sending end does not send the original TS domain value any more, but sends the value reduced proportionally, if TS _ STRIDE is increased proportionally, TS _ STRIDE does not appear in the compressed message, namely TS _ SCA L ED value is increased along with the increase of SN, the two are synchronous, therefore, the message with the highest compression ratio is UO-0 packet under O mode, UO-0 packet is shown in FIG. 2, the message has only 1 byte, SN field occupies 4 bits, a K value is defined here, K is the least significant bit of SN in the data packet, therefore, K value here is 4.
When the data is transmitted once every 20ms during the active period of the user talk state for the duration of voice, the state of the user talk pause is interrupted by 160ms, during the silence packet, some samples are discarded, so the TS of the RTP packet is continuously incremented, but the SN of the RTP is not continuously incremented, in general, the data of the first 7 samples is discarded, so in the silence period, a silence sid (silence descriptor) packet is generated every 20 × 8 ms, so the increment of the TS may become 8 × 160 or 8 × 320, depending on the number of discarded samples forming a packet, which is called silence suppression, at which the receiving end may not parse normally if the TS is transmitted with the highest transmit end formula, therefore in the case of TS _ STRIDE change, it is necessary to use a larger compressed packet to pass TS _ STRIDE change, for example, a data packet of the type UOR-2 type may be used to carry an extended ext3, an IR-DYN packet or an IR packet, which is at least 7 or 8 bits, so that the TS-TS equivalent to a longer TS-snr change is needed to send a TS-TS equivalent to a TS equivalent to a more efficient TS equivalent TS-based on the extended TS-SN field length of the TS-52, so that the TS-TS equivalent TS-TS equivalent to a more efficient TS equivalent TS-TS equivalent TS-TS equivalent to a payload length TS-equivalent to a longer TS-TS equivalent to a more efficient, such as a TS-equivalent, a more efficient, a TS-TS.
It can be seen from fig. 3 that only 3 bytes are needed to indicate the TS change between two adjacent SDU packets. This results in better compression efficiency and bandwidth utilization when muting and activation interconversions are more frequent. It is generally set that after the same TS difference value repeatedly appears after N consecutive times (N >3), the extension ext3, IR-DYN packet or IR packet is carried by the UOR-2 to notify the TS _ STRIDE change and this type of packet is transmitted multiple times so that the receiving end (the de-transmitting end) can reliably receive the TS _ STRIDE. It should be noted that each type of packet refers to a header compressed based on the ROHC protocol.
For a compressed voice message in an UM mode, when a packet loss occurs, a wireless access layer protocol cannot retransmit, ROHC contexts at two ends may be inconsistent, and at this time, a CRC failure occurs at a decompression end, NACK or S-NACK is fed back to the compression end to notify the decompression failure, and the compression end can be in a transition state to send a longer message carrying more information for synchronizing the contexts.
Based on this, in a first aspect, an embodiment of the present invention provides a method for processing a voice packet loss, as shown in fig. 4, including:
s101, when a packet loss event of an SDU packet of a voice service data unit is determined and the packet loss event causes a receiving end to be incapable of correctly analyzing the received SDU packet, performing header compression again on a head node SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol, enabling a compressed message header to carry indication information for enabling the receiving end to know a timestamp of the head node SDU packet, and transmitting the head node SDU packet to the receiving end;
s102, updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in a queue to be sent based on an ROHC protocol according to the updated context.
In the voice packet loss processing method provided by the embodiment of the present invention, when it is determined that a packet loss event occurs and the packet loss event affects normal parsing of a receiving end, a header SDU in a queue to be transmitted is re-compressed, so that an indication information capable of indicating a timestamp of the header SDU packet is carried in a compressed packet header, the header SDU packet is transmitted to the receiving end, and then other SDU packets in the queue are re-compressed according to ROHC updated by the transmitting end and transmitted to the receiving end. Therefore, the receiving end can update the ROHC context of the receiving end according to the indication information carried by the head node SDU, and can correctly analyze the next received SDU, so that the condition that more data packets cannot be correctly analyzed due to continuous transmission of the data packets in the queue in packet loss feedback can not occur, the further deterioration of the packet loss rate can be effectively prevented, meanwhile, the receiving end can be prevented from causing meaningless state migration due to decompression failure, and the whole packet loss processing process is enabled to be simple and efficient.
Here, the ROHC compression context here is specifically: when the header compression technology is implemented, information obtained from past messages needs to be stored, and the place where the information is stored can be understood as context. In one context, context information is used to compress or decompress the last message. In order to enable the receiving end to correctly parse the data packet, the ROHC context of the transmitting end should be synchronized with the ROCH context of the receiving end.
In addition, it should be noted that the sending end may be one of a network side device (e.g., a base station) and a terminal device, and the receiving end may be the other, which is not specifically limited in the present invention.
In specific implementation, the determining the occurrence of the packet loss event of the voice service data unit SDU in S101 may be implemented in various ways, and several alternative implementations are described below.
And (I) the media access control MAC layer fails to send the voice SDU.
For example, a TBSize first transmission feeds back NACK, and NACK is fed back until the maximum retransmission times, the packet is counted as a packet loss, and the packet may include a plurality of SDUs (the characteristics of re-segmentation and concatenation of R L C).
And (II) discarding the SDU packet by the PDCP layer due to the overtime of the timer.
When SDU is sent in the empty port (MAC scheduling), the PDCP layer judges whether the phenomenon of discarding SDU packets caused by overtime of a discarding timer exists in the SDU in a queue to be sent. Wherein, the discard timer is generally configured to be 100ms, and the calculation method is Tcur-Tarrive＞Tdiscard，TcurIs the current time, TarriveFor packet arrival time, TdiscardIs the set discard timing. If this condition is satisfied, the PDCP layer discards the SDU packet due to the timeout of the timer, that is, a packet loss event occurs.
Similarly, if the TS _ Stride changes during the packet loss process, the PDCP entity will also record the change of the TS _ Stride in the discarded SDU voice packet during recording.
And (III) receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
If the receiving end can not decompress normally, the receiving end can carry out negative feedback to the sending end immediately, particularly NACK or SNACK can be fed back, and therefore the sending end can know that a packet loss event occurs currently.
It should be noted that, the above are only some exemplary embodiments for detecting occurrence of a packet loss event, and in practical applications, the present invention may also be implemented by other feasible manners, which is not limited in this respect.
No matter which way the occurrence of the packet loss event is detected, after the event is detected, the receiving end can immediately determine whether the packet loss event can affect the normal receiving of the receiving end. If not, then SDU packets in the transmission queue can be transmitted as usual without recompression; if the packet is affected, the head node SDU packet in the sending queue needs to be recompressed immediately, so that the receiving end can update the ROHC context in time after the head node SDU packet is sent to the receiving end, and more packet loss is avoided. In practical applications, the process of determining whether the packet loss event affects normal reception of the receiving end in S101 may have various situations, and the corresponding compression processing may also have various ways, and several of the situations are described in detail below.
In case one, if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the last SDU packet successfully sentlastTime stamp TSlastAnd serial number SN corresponding to head node SDU packet of queue to be sentfirstTime stamp TSfirstIf the time stamp proportional value TS _ Scale is obtained to increase proportionally, but the packet loss number is more than 2kIf k is a positive integer and is used for representing the least significant bit of the serial number SN of the data packet type corresponding to the SDU packet which is successfully sent for the last time, determining that a packet loss event causes that a receiving end cannot correctly analyze the received SDU packet;
at this time, the recompression procedure for the head node SDU may be: according to SNlastAnd SNfirstObtaining SNlastL sb, and based on L sb, selects a channel capable of carrying SNlastThe data packet of (1); according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed message head carries SNlast。
Specifically, whether the TS _ Stride has changed during packet loss is known to the transmitting end itself, and the case one illustrates is a case where the TS _ Stride has not changed. When the TS _ Stride is not changed, the value of the TS _ Stride does not need to be notified to the receiving end, so that it is only necessary to determine whether the TS _ Scale is increased proportionally in the packet loss process. Next, a way to determine whether TS _ Scale is increased proportionally in the packet loss process is described.
Because of the existence of the feedback channel, the following description is that the header compression is in the O mode, the compression side is in the SO state, and the decompression side is in the FC state. And the PDCP will record the SN, TS _ Stride being used, and packet type of the RTP voice packet corresponding to the last successfully transmitted SDU.
The related information of the RTP voice packet corresponding to the last successfully transmitted SDU is marked as follows: sequence number SN: SN (service provider)lastAnd time stamp: TS (transport stream)last. Marking the related information of the RTP voice packet corresponding to the head node SDU packet of the queue to be sent as follows: sequence number SN: SN (service provider)firstAnd time stamp: TS (transport stream)first。
Judging whether the TS _ Scale is increased in proportion in the packet loss process according to the formula (2):
if(SNfirst-SNlast)＝＝((TSfirst-TSlast)/TS_Stride) (2)
if the two are equal, TS _ SCA L E is increased proportionally, then the last successfully transmitted data packet type is obtained, the length of SN in the data packet type is obtained, for example, k is 4(k is also the length of SN) for data packets of UO-0 and UO-1 type, k is 6 for data packets of UO-2 typekThe magnitude relationship of (1).
(I) If the packet loss data is less than or equal to 2kThe receiving end can successfully analyze within the interpretation interval without recompression.
This is because, for SCA L E corresponding to SN and TS of 16-bit RTP, encoding is performed by W L SB, the transmitting end only transmits K least significant bits of the original value, where K is a positive integer, and after receiving K bits, the decompressing party uses the correctly received value as a reference value to restore the original value, and to ensure the correctness of this scheme, the transmitting end and the decompressing party use the interpretation interval shown in equation (3), and the specific principle refers to fig. 5:
f(v_ref，k)＝[v_ref-p，v_ref+(2^k-1)-p](3)
where v _ ref is a reference value and P is introduced to shift the decoding interval relative to the reference value v _ ref. For values that are expected to always increase, P may be set to-1.
In short, when the TS _ Scale increases proportionally, the TS _ Scale increases with the increase of the SN, and at this time, the data packet may not carry the value of the TS _ Scale, and the receiving end may deduce the value of the TS _ Scale according to the SN in the received data packet, so as to determine the timestamp TS. This therefore requires that the value of the SN carried in the data packet be accurate. SN is the sequence number of each SDU, which also increases as the number of transmitted SDU packets increases, and may only need to be represented by 3 bits at the beginning and 5 bits later as the SN increases. If the packet loss data is less than or equal to 2 according to the judgmentkThen, the type used by the data packet of the last successfully transmitted SDU still used by the head node SDU packet of the transmission queue can correctly represent its SN, so that the receiving end can successfully parse within the interpretation interval at this time, and further, the SDUs in the queue can not be recompressed.
(II) if the number of packet losses is greater than 2kTherefore, L sb bit of the expanded SN value is needed, so that the receiving end can know the correct L sb bit of the expanded SN value SN., which means that the SN can be satisfied when the receiving end needs to be replacedfirstL sb bits the selection of the packet type may be made in the following manner.
Obtaining SN according to equation (4)firstL sb bit number:
Lsb＝SNLast^SNFirst(4)
further obtain bit number L enh of L sbLsbWhereas the length of L sb in type t of flag packet (i.e. existing data packets based on several standards set by the ROHC protocol, e.g. UO-0, UO-2, etc.) is L enthtTherefore, only L nth can be fetchedLsb>＝LenthtSo that it can be satisfied that the correct SN is carriedfirst。
For example, a transition from a UO-0 type to a UOR-2 type. If the bit number of the SN in the basic packet (data packet without the extension field) type is not enough, extension types with different lengths in the UOR-2 are needed to carry the SN value. After selecting the data packet meeting the conditions according to the rule, SN in the head node SDU packetfirstThe field value can be filled in according to equation (5), where k is the value of k corresponding to the newly selected data packet.
Lsb＝(SNFirst&((1<<k)-1) (5)
That is, in the process of header re-compressing the header node SDU packet, the compressed packet header has SN carried in the extended fieldfirstThen, the head node SDU is sent to the receiving end for the receiving end to update its ROHC context.
Then, the sending end can update the ROHC context of the sending end, and carries out head re-compression on other SDUs in the array to be sent according to the updated context, and the compressed SDUs are sent to the receiving end in sequence, and at the moment, the receiving end can normally analyze the data packets.
And in case II, if the TS _ Stride is not changed in the packet loss process, according to the SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining a packet loss event so that a receiving end cannot correctly analyze the received SDU packet;
at this time, selecting a data packet with an extended field; according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed message head carries SNfirstAnd TSfirst。
Specifically, if the sender knows that TS _ Stride does not change during packet loss and that the results of equation (2) are not equal, that is, it indicates that TS _ SCA L E does not increase proportionally due to silence activation and inter-conversion that may occur during packet loss, such a situation is followedThe receiving end is also unable to analyze normally. In this case, the data packet with the extension field, for example, the UOR-2 data packet, can be directly selected to carry the SN in the extension fieldfirstAnd TSfirstFig. 6 shows one type of extension that a UOR-2 packet may carry. SN (service provider)firstThe manner of acquiring the least significant bit and the manner of filling in the extended field are the same as in case one, and are not described herein again. TS (transport stream)firstThe value carries the R-Ts field in Extension 3 (this field is set to 1) as in fig. 6, i.e. the original Ts value is carried with self-descriptive variable length coding, 4 bytes maximum.
SN is carried in head node SDU packet after being compressed according to the above rulefirstAnd TSfirstAfter sending it to the receiving end, the receiving end can update its own ROHC context. Then, the sending end can update the ROHC context of itself, and carries out head-renewed compression on other SDU packets in the queue according to the updated context, and then sends the SDU packets to the receiving end in sequence. At this time, the receiving end can perform normal parsing on the data.
If the TS _ Stride changes in the packet loss process, determining a packet loss event so that the receiving end cannot correctly analyze the received SDU packet;
then the packet with the extended field is selected at this time; according to the type of the selected data packet, head compression is carried out again on the head node SDU packet based on the ROHC protocol, so that the compressed packet head carries TSfirstAnd a changed TS _ Stride, wherein TSfirstIndicating the header SDU packet timestamp.
Specifically, the sending end itself can know whether the TS _ Stride changes in the packet loss process. If TS _ Stride changes, then TS _ Scale must have been incremented non-proportionally by SN. At this time, the data packet with the extension field can be directly selected, for example, using UOR-2 to carry the new TS _ Stride value and the TS value. Fig. 7 shows another format of an extension type. Wherein, TSfirstThe value is carried in the R-Ts domain of Extension 3, i.e. coded using self-descriptive variable length coding, with a maximum of 4 bytes. The changed TS _ Stride value adopts self-descriptive variable lengthThe encoding carries the TSS sub-field in the RTP field of Extension 3, with a maximum of 4 bytes.
The compressed head node SDU packet according to the above rule carries TSfirstAnd the changed TS _ Stride value, and after sending it to the receiving end, the receiving end can update its own ROHC context. Then, the sending end can update the ROHC context of itself, and carries out head-renewed compression on other SDU packets in the queue according to the updated context, and then sends the SDU packets to the receiving end in sequence. At this time, the receiving end can perform normal parsing on the data.
The three situations can be represented by the flowchart shown in fig. 8, and since each situation has been specifically described above, it is not described herein again.
In a second aspect, an embodiment of the present invention further provides a device for processing a packet loss in voice, as shown in fig. 9, including:
a first compression processing unit 201, configured to, when it is determined that a packet loss event occurs in an SDU packet of a voice service data unit and the packet loss event causes a receiving end to be unable to correctly analyze a received SDU packet, perform header compression again on a header SDU packet in a queue to be sent based on a robust header compression ROHC protocol, so that an indication information for making the receiving end know a timestamp of the header SDU packet is carried in a compressed packet header, and send the header SDU packet to the receiving end;
the second compression processing unit 202 is configured to update a local ROHC compression context, and perform header compression again on SDU packets of other nodes in the to-be-sent queue based on an ROHC protocol according to the updated context.
Optionally, the determining that the packet loss event of the voice service data unit SDU includes: detecting at least one event occurrence of:
the media access control MAC layer fails to send the voice SDU;
the PDCP layer discards the SDU packet due to the overtime of the timer;
and receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
Optionally, the first compression processing unit 201 is configured to:
if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the SDU packet successfully sent at the last timelastTime stamp TSlastAnd serial number SN corresponding to head node SDU packet of queue to be sentfirstTime stamp TSfirstKnowing that the timestamp proportional value TS _ Scale increases proportionally but the number of packet losses is greater than 2kIf so, determining that the packet loss event causes the receiving end not to correctly analyze the received SDU packet; k is a positive integer and is used for representing the least significant bit of the SN of the data packet type corresponding to the SDU packet which is successfully sent at the last time;
and is also used for:
according to SNlastAnd SNfirstObtaining SNfirstL sb;
according to the least significant bit L sb, selecting the SN capable of being carriedfirstThe data packet of (1);
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirst。
Optionally, the first compression processing unit 201 is configured to:
if the TS _ Stride is not changed in the packet loss process, and according to the SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining that the packet loss event causes the receiving end to be incapable of correctly analyzing the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirstAnd TSfirst。
Optionally, the first compression processing unit 201 is configured to:
if the TS _ Stride changes in the packet loss process, determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the TSfirstAnd a changed TS _ Stride, wherein the TS isfirstIndicating the header SDU packet timestamp.
Since the packet loss processing device described in this embodiment is a device capable of executing the packet loss processing method in this embodiment of the present invention, based on the packet loss processing method described in this embodiment of the present invention, those skilled in the art can understand the specific implementation manner and various variations of the packet loss processing device in this embodiment, so that how to implement the packet loss processing method in this embodiment of the present invention by using the packet loss processing device is not described in detail here. As long as a person skilled in the art implements the apparatus used in the method for processing packet loss in the embodiment of the present invention, the apparatus is within the scope of the present application.
Fig. 10 is a block diagram showing a configuration of a computer device according to an embodiment of the present invention.
Referring to fig. 10, the computer apparatus includes: a processor (processor)301, a memory (memory)302, a bus 303, and a bus interface 304;
the processor 301 and the memory 302 complete mutual communication through the bus 303, and the bus interface 304 is used for information interaction with external devices;
the processor 301 is configured to call program instructions in the memory 302 to perform the methods provided by the above-mentioned method embodiments, including: when determining that a packet loss event of an SDU packet of a voice service data unit occurs and the packet loss event causes a receiving terminal to be incapable of correctly analyzing the received SDU packet, performing header compression again on a header SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol, so that an indication information for enabling the receiving terminal to acquire a timestamp of the header SDU packet is carried in a compressed packet header, and transmitting the header SDU packet to the receiving terminal; and updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
Embodiments of the present invention also disclose a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, which when executed by a computer, enable the computer to perform the methods provided by the above-mentioned method embodiments, for example, including: when determining that a packet loss event of an SDU packet of a voice service data unit occurs and the packet loss event causes a receiving terminal to be incapable of correctly analyzing the received SDU packet, performing header compression again on a header SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol, so that an indication information for enabling the receiving terminal to acquire a timestamp of the header SDU packet is carried in a compressed packet header, and transmitting the header SDU packet to the receiving terminal; and updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
Embodiments of the present invention further provide a non-transitory computer-readable storage medium, where the non-transitory computer-readable storage medium stores computer instructions, where the computer instructions cause the computer to perform the methods provided by the foregoing method embodiments, for example, the method includes: when determining that a packet loss event of an SDU packet of a voice service data unit occurs and the packet loss event causes a receiving terminal to be incapable of correctly analyzing the received SDU packet, performing header compression again on a header SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol, so that an indication information for enabling the receiving terminal to acquire a timestamp of the header SDU packet is carried in a compressed packet header, and transmitting the header SDU packet to the receiving terminal; and updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
Furthermore, those skilled in the art will appreciate that while some embodiments herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.
Some component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functionality of some or all of the components of a gateway, proxy server, system according to embodiments of the present invention. The present invention may also be embodied as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.

Claims (12)

1. A method for processing voice packet loss is characterized by comprising the following steps:
when determining that a packet loss event of an SDU packet of a voice service data unit occurs and the packet loss event causes a receiving end to be incapable of correctly analyzing the received SDU packet, determining whether the packet loss event can affect the normal receiving of the receiving end by adopting different determination modes, and performing header compression again on a head node SDU packet in a queue to be transmitted based on a robust header compression ROHC protocol by adopting a compression processing mode corresponding to the determination mode, so that an indication information for enabling the receiving end to know a timestamp of the head node SDU packet is carried in a compressed packet header, and the head node SDU packet is transmitted to the receiving end;
and updating a local ROHC compression context, and performing head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
2. The method of claim 1, wherein the determining that a voice Service Data Unit (SDU) packet loss event occurs comprises: detecting at least one event occurrence of:
the media access control MAC layer fails to send the voice SDU;
the PDCP layer discards the SDU packet due to the overtime of the timer;
and receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
3. The method of claim 1, wherein determining that the packet loss event causes a receiving end to fail to correctly parse the received SDU packet comprises:
if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the SDU packet successfully sent at the last timelastTime stamp TSlastAnd the sequence corresponding to the head node SDU packet of the queue to be sentNumber SNfirstTime stamp TSfirstKnowing that the timestamp proportional value TS _ Scale increases proportionally but the number of packet losses is greater than 2kIf so, determining that the packet loss event causes the receiving end not to correctly analyze the received SDU packet; k is a positive integer and is used for representing the least significant bit of the SN of the data packet type corresponding to the SDU packet which is successfully sent at the last time;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
according to SNlastAnd SNfirstObtaining SNfirstL sb;
according to the least significant bit L sb, selecting the SN capable of being carriedfirstThe data packet of (1);
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirst。
4. The method of claim 1, wherein determining that the packet loss event causes a receiving end to fail to correctly parse the received SDU packet comprises:
if the TS _ Stride is not changed in the packet loss process, and according to the SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining that the packet loss event causes the receiving end to be incapable of correctly analyzing the received SDU packet;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
selecting a data packet with an extended field;
according to the type of the selected data packet, the head compression is carried out again on the head node SDU packet based on the ROHC protocol, so that the pressure is ensuredThe SN is carried in the contracted message headerfirstAnd TSfirst。
5. The method of claim 1, wherein determining that the packet loss event causes a receiving end to fail to correctly parse the received SDU packet comprises:
if the TS _ Stride changes in the packet loss process, determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet;
the said head node SDU packet in the queue to be sent carries on the head again to compress on the basis of the robust header compression ROHC agreement, make the compressed message header carry and use for making the receiving end know the said head node SDU packet indicator information of time stamp, including:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the TSfirstAnd a changed TS _ Stride, wherein the TS isfirstIndicating the header SDU packet timestamp.
6. A voice packet loss processing apparatus, comprising:
the first compression processing unit is used for determining whether the packet loss event can affect the normal receiving of the receiving end by adopting different determining modes when the occurrence of the voice service data unit SDU packet loss event is determined and the packet loss event enables the receiving end not to correctly analyze the received SDU packet, and performing head compression on the head node SDU packet in the queue to be sent again by adopting a compression processing mode corresponding to the determining mode based on a robust packet head compression ROHC protocol so that the compressed packet head carries indication information for enabling the receiving end to know the timestamp of the head node SDU packet, and sending the head node SDU packet to the receiving end;
and the second compression processing unit is used for updating the local ROHC compression context and carrying out head compression again on SDU packets of other nodes in the queue to be sent based on an ROHC protocol according to the updated context.
7. The apparatus of claim 6, wherein the determining that a voice Service Data Unit (SDU) packet loss event occurs comprises: detecting at least one event occurrence of:
the media access control MAC layer fails to send the voice SDU;
the PDCP layer discards the SDU packet due to the overtime of the timer;
and receiving negative feedback sent by the receiving end, wherein the negative feedback is used for indicating that the receiving end fails to check the received SDU packet.
8. The apparatus of claim 6, wherein the first compression processing unit is configured to:
if the timestamp step value TS _ Stride is not changed in the packet loss process, and according to the serial number SN corresponding to the SDU packet successfully sent at the last timelastTime stamp TSlastAnd serial number SN corresponding to head node SDU packet of queue to be sentfirstTime stamp TSfirstKnowing that the timestamp proportional value TS _ Scale increases proportionally but the number of packet losses is greater than 2kIf so, determining that the packet loss event causes the receiving end not to correctly analyze the received SDU packet; k is a positive integer and is used for representing the least significant bit of the SN of the data packet type corresponding to the SDU packet which is successfully sent at the last time;
and is also used for:
according to SNlastAnd SNfirstObtaining SNfirstL sb;
according to the least significant bit L sb, selecting the SN capable of being carriedfirstThe data packet of (1);
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirst。
9. The apparatus of claim 6, wherein the first compression processing unit is configured to:
if the TS _ Stride is not changed in the packet loss process, and according to the SNlast、TSlast、SNfirstAnd TSfirstIf the TS _ Scale is increased in a non-proportional way, determining that the packet loss event causes the receiving end to be incapable of correctly analyzing the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the SNfirstAnd TSfirst。
10. The apparatus of claim 6, wherein the first compression processing unit is configured to:
if the TS _ Stride changes in the packet loss process, determining that the packet loss event causes the receiving end to be unable to correctly analyze the received SDU packet;
and is also used for:
selecting a data packet with an extended field;
according to the type of the selected data packet, head compression is carried out on the head node SDU packet again based on the ROHC protocol, so that the compressed packet head carries the TSfirstAnd a changed TS _ Stride, wherein the TS isfirstIndicating the header SDU packet timestamp.
11. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method according to any of claims 1 to 5 are implemented when the program is executed by the processor.
12. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 5.
CN201710538087.1A 2017-07-04 2017-07-04 Voice packet loss processing method and device Active CN109219078B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710538087.1A CN109219078B (en) 2017-07-04 2017-07-04 Voice packet loss processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710538087.1A CN109219078B (en) 2017-07-04 2017-07-04 Voice packet loss processing method and device

Publications (2)

Publication Number Publication Date
CN109219078A CN109219078A (en) 2019-01-15
CN109219078B true CN109219078B (en) 2020-07-28

Family

ID=64992972

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710538087.1A Active CN109219078B (en) 2017-07-04 2017-07-04 Voice packet loss processing method and device

Country Status (1)

Country Link
CN (1) CN109219078B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112333769B (en) * 2019-08-05 2022-10-11 华为技术有限公司 Communication method and device
CN112953847B (en) * 2021-01-27 2022-11-11 北京字跳网络技术有限公司 Network congestion control method and device, electronic equipment and storage medium
CN115334588A (en) * 2021-05-10 2022-11-11 华为技术有限公司 Data transmission method and device
CN114339640B (en) * 2022-01-11 2023-04-07 赛特斯信息科技股份有限公司 ROHC-based 5G voice transmission method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045132A (en) * 2009-10-23 2011-05-04 华为技术有限公司 Retransmission mechanism-based method and device for transmitting header compression data packet
CN102137439A (en) * 2010-09-17 2011-07-27 上海华为技术有限公司 Compression control method, device and system
CN105791228A (en) * 2014-12-22 2016-07-20 中兴通讯股份有限公司 Method and device for compressing timestamp
CN106856424A (en) * 2015-12-09 2017-06-16 普天信息技术有限公司 The ROHC message transmitting method for compressing and system in a kind of VOLTE systems

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130188758A1 (en) * 2012-01-24 2013-07-25 Broadcom Corporation Joint source channel decoding using parameter domain correlation
US9923695B2 (en) * 2014-09-24 2018-03-20 Samsung Electronics Co., Ltd. Call processing method and apparatus for use in LTE system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045132A (en) * 2009-10-23 2011-05-04 华为技术有限公司 Retransmission mechanism-based method and device for transmitting header compression data packet
CN102137439A (en) * 2010-09-17 2011-07-27 上海华为技术有限公司 Compression control method, device and system
CN105791228A (en) * 2014-12-22 2016-07-20 中兴通讯股份有限公司 Method and device for compressing timestamp
CN106856424A (en) * 2015-12-09 2017-06-16 普天信息技术有限公司 The ROHC message transmitting method for compressing and system in a kind of VOLTE systems

Also Published As

Publication number Publication date
CN109219078A (en) 2019-01-15

Similar Documents

Publication Publication Date Title
EP2452480B1 (en) Backward looking robust header compression receiver
CN109219078B (en) Voice packet loss processing method and device
JP3559019B2 (en) System and method for achieving robust IP / UDP / RTP header compression in the presence of untrusted networks
JP5084842B2 (en) Improved header compression in wireless communication networks
AU2003248437B2 (en) Packet Transmission System and Packet Reception System
EP1271886B1 (en) Packet header compression
JP5278532B2 (en) Reception device, transmission device, reception method, transmission method, communication system, and communication method
US9031071B2 (en) Header elimination for real time internet applications
US7730380B2 (en) Method and apparatus for transmitting/receiving voice over internet protocol packets with a user datagram protocol checksum in a mobile communication system
WO2006052117A1 (en) Apparatus and method for compressing headers in a broadband wireless communication system
AU5862000A (en) Robust header compression in packet communications
KR20170004598A (en) Method and apparatus for communicating packets using header compression
JP4856251B2 (en) Header suppression in wireless communication networks
EP1482668A1 (en) PACKET TRANSMITTER&amp;comma; PACKET RECEIVER AND PACKET TRANSMISSION METHOD
US20040165542A1 (en) Packet transmitter and packet transmitter method
Tömösközi et al. Performance evaluation of network header compression schemes for UDP, RTP and TCP
Maeder et al. Performance evaluation of ROHC reliable and optimistic mode for voice over LTE
CN108574684B (en) Decompression method and device
WO2017067224A1 (en) Packet processing method and apparatus
CN108737349B (en) Voice data packet processing method and device
CN107548105B (en) Data transmission confirmation method based on UDP (user Datagram protocol) and base station
CN109246063B (en) L SB (Business card Specification) wrapping optimization method and device
CN109936864A (en) A kind of method and apparatus across building head compressed context in the switching of station
US20040136380A1 (en) Packet transmitter, packet receiver and packet transmission method
CN109219079B (en) IR message transmission method and communication equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant