Data transmission method and apparatus, communication device, and readable storage medium

Abstract

The present application relates to the technical field of communications, and discloses a data transmission method and apparatus, a communication device, and a readable storage medium. The data transmission method in embodiments of the present application comprises: a first node sends a first data packet to a second node, wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of the following: static field information of a real-time transport protocol (RTP) header; static field information of a user datagram protocol (UDP) header; and static field information of an Internet protocol (IP) header.

Description

Data transmission method and device, communication device and readable storage medium

[0001] Cross-reference to Related Applications

[0002] The present application claims priority to Chinese Patent Application No. 202411386467.4, filed on September 30, 2024, the contents of which are incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application belongs to the field of communication technology, and specifically relates to a data transmission method and device, a communication device and a readable storage medium. BACKGROUND

[0004] In related technologies, for the transmission of service data packets, the service data packets are usually encapsulated by real-time protocol (RTP), user datagram protocol (UDP) and Internet protocol (IP) after being generated and then transmitted, and when these data are transmitted as application layer data through an access stratum (AS) protocol stack, they also need to be encapsulated by a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer and a medium access control (MAC) layer before being transmitted through a physical layer via an air interface. As a result, a large amount of protocol header overhead will be generated after the service data packets are encapsulated layer by layer, thereby causing a large header overhead. SUMMARY

[0005] Embodiments of the present application provide a data transmission method and device, a communication device and a readable storage medium, which can solve the problem of large header overhead in existing data transmission.

[0006] In a first aspect, a data transmission method is provided, which is performed by a first node, and the method comprises:

[0007] The first node sends a first data packet to a second node; wherein the first data packet comprises static domain information of a header, and the static domain information of the header comprises at least one of the following:

[0008] Static domain information of a real-time transport protocol (RTP) header;

[0009] Static domain information of a user datagram protocol (UDP) header;

[0010] Static domain information of an Internet protocol (IP) header.

[0011] In a second aspect, a data transmission method is provided, performed by a second node, comprising:

[0012] The second node receives a first data packet sent by the first node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of:

[0013] static field information of a real-time transport protocol (RTP) header;

[0014] static field information of a user datagram protocol (UDP) header;

[0015] static field information of an internet protocol (IP) header.

[0016] In a third aspect, a data transmission apparatus is provided, applied to a first node, comprising:

[0017] a first sending module, configured to send a first data packet to a second node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of:

[0018] static field information of a real-time transport protocol (RTP) header;

[0019] static field information of a user datagram protocol (UDP) header;

[0020] static field information of an internet protocol (IP) header.

[0021] In a fourth aspect, a data transmission apparatus is provided, applied to a second node, comprising:

[0022] a second receiving module, configured to receive a first data packet sent by a first node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of:

[0023] static field information of a real-time transport protocol (RTP) header;

[0024] static field information of a user datagram protocol (UDP) header;

[0025] static field information of an internet protocol (IP) header.

[0026] In a fifth aspect, a data transmission apparatus is provided, configured to perform the steps of the method according to the first aspect, or implement the steps of the method according to the second aspect.

[0027] In a sixth aspect, a terminal is provided, comprising a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method according to the first aspect, or implement the steps of the method according to the second aspect.

[0028] In a seventh aspect, a terminal is provided, comprising a processor and a communication interface, the communication interface being configured to send a first data packet to a network-side device or receive a first data packet sent by the network-side device; the first data packet comprising static field information of a header, the static field information of the header comprising at least one of: static field information of an RTP header; static field information of a UDP header; static field information of an IP header.

[0029] In an eighth aspect, a network-side device is provided, comprising a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions being executed by the processor to implement the steps of the method according to the first aspect, or implement the steps of the method according to the second aspect.

[0030] In a ninth aspect, a network-side device is provided, comprising a processor and a communication interface, the communication interface being configured to send a first data packet to a terminal or receive a first data packet sent by the terminal; the first data packet comprising static field information of a header, the static field information of the header comprising at least one of: static field information of an RTP header; static field information of a UDP header; static field information of an IP header.

[0031] In a tenth aspect, a readable storage medium is provided, the readable storage medium storing programs or instructions, the programs or instructions being executed by a processor to implement the steps of the method according to the first aspect, or implement the steps of the method according to the second aspect.

[0032] In an eleventh aspect, a wireless communication system is provided, comprising a terminal and a network-side device, the terminal being configured to implement the steps of the method according to the first aspect, and the network-side device being configured to implement the steps of the method according to the second aspect; or the terminal being configured to implement the steps of the method according to the second aspect, and the network-side device being configured to implement the steps of the method according to the first aspect.

[0033] In a twelfth aspect, a chip is provided, comprising a processor and a communication interface, the communication interface being coupled to the processor, the processor being configured to run programs or instructions to implement the method according to the first aspect, or implement the method according to the second aspect.

[0034] In a thirteenth aspect, a computer program / program product is provided, the computer program / program product being stored in a storage medium, the computer program / program product being executed by at least one processor to implement the steps of the method according to the first aspect, or implement the steps of the method according to the second aspect.

[0035] Through the scheme of the embodiments of the present application, the static field information of the first data packet transmission header can be transmitted in advance or only part of the static field information of the data packet transmission header can be transmitted, so that the subsequent user plane transmission data packet can not carry the static field information of the header, but restore the corresponding static field information of the header based on the static field information of the header transmitted in advance or obtained in advance, thereby reducing the header overhead and improving the transmission efficiency of effective data. BRIEF DESCRIPTION OF DRAWINGS

[0036] FIG. 1 shows a block diagram of a wireless communication system to which embodiments of the present application can be applied;

[0037] FIG. 2 is a flowchart of a data transmission method according to an embodiment of the present application;

[0038] FIG. 3 is a flowchart of another data transmission method according to an embodiment of the present application;

[0039] FIG. 4 is a flowchart of a data transmission process according to an embodiment of the present application;

[0040] FIG. 5 is a flowchart of a data transmission process according to another embodiment of the present application;

[0041] FIG. 6A is a flowchart of a data transmission process according to a third embodiment of the present application;

[0042] FIG. 6B is a flowchart of a data transmission process according to a fourth embodiment of the present application;

[0043] FIG. 7 is a schematic structural diagram of a data transmission apparatus according to an embodiment of the present application;

[0044] FIG. 8 is a schematic structural diagram of another data transmission apparatus according to an embodiment of the present application;

[0045] FIG. 9 is a schematic structural diagram of a communication device according to an embodiment of the present application;

[0046] FIG. 10 is a schematic structural diagram of a terminal according to an embodiment of the present application;

[0047] FIG. 11 is a schematic structural diagram of a network side device according to an embodiment of the present application. DETAILED DESCRIPTION

[0048] The technical solutions in the embodiments of the present application will be described clearly below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art belong to the scope of protection of the present application.

[0049] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, the scope of protection for "A or B" covers at least three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. In addition, the terms "A and / or B," "at least one of A and B," and "at least one of A or B" also cover at least the above three scenarios. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0050] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc., in the instruction sent. An indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0051] It is worth noting that the technology described in the embodiments of the present application is not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA) or other systems. The terms "system" and "network" in the embodiments of the present application are often used interchangeably, and the described technology can be used in the above-mentioned systems and radio technologies, as well as in other systems and radio technologies. The following description describes a New Radio (NR) system for example purposes, and NR terminology is used in most of the following description, but these technologies can also be applied to systems other than NR systems, such as 6th Generation (6G) communication systems. th

[0052] ​FIG. 1 shows a block diagram of a wireless communication system to which embodiments of the present application can be applied. The wireless communication system includes a terminal 11 and a network-side device 12. The terminal 11 can be a terminal-side device such as a mobile phone, a Tablet Personal Computer, a Laptop Computer, a notebook computer, a Personal Digital Assistant (PDA), a palmtop computer, a netbook, an Ultra-mobile Personal Computer (UMPC), a Mobile Internet Device (MID), an Augmented Reality (AR) device, a Virtual Reality (VR) device, a robot, a wearable device, a flight vehicle, a Vehicle User Equipment (VUE), a shipboard device, a Pedestrian User Equipment (PUE), a smart home (a home device with a wireless communication function such as a refrigerator, a television, a washing machine, or furniture), a game console, a Personal Computer (PC), a kiosk, or a self-service machine. The wearable device includes a smart watch, a smart bracelet, a smart earphone, smart glasses, smart jewelry (a smart bracelet, a smart necklace, a smart ring, a smart necklace, a smart anklet, a smart necklace, etc.), a smart wristband, smart clothing, etc. The vehicle-mounted device can also be referred to as a vehicle-mounted terminal, a vehicle-mounted controller, a vehicle-mounted module, a vehicle-mounted component, a vehicle-mounted chip, or a vehicle-mounted unit, etc. It should be noted that the specific type of the terminal 11 is not limited in the embodiments of the present application. The network-side device 12 can include an access network device or a core network device. The access network device can also be referred to as a Radio Access Network (RAN) device, a radio access network function, or a radio access network unit. The access network device can include a base station, a Wireless Local Area Network (WLAN) Access Point (AP), or a Wireless Fidelity (WiFi) node, etc.The base station can be referred to as a node B (NB), an evolved node B (eNB), a next generation node B (gNB), a new radio node B (NR node B), an access point, a relay base station (RBS), a serving base station (SBS), a base transceiver station (BTS), a radio base station, a radio transceiver, a basic service set (BSS), an extended service set (ESS), a home node B (HNB), a home evolved node B, a transmit / receive point (TRP), or some other suitable terminology in the art, as long as the same technical effect is achieved. The base station is not limited to a specific technical term, and it should be noted that only the base station in the NR system is taken as an example for introduction in the embodiments of the present application, and the specific type of the base station is not limited.

[0053] It should be noted that the service scenarios to which the embodiments of the present application are applicable can include, but are not limited to, satellite voice service scenarios and the like. Since high-orbit satellite communication has the advantages of wide coverage and high industrial maturity, it has great potential in voice communication demand in remote environments such as oceans and deserts. By supporting narrowband voice through high-orbit satellites, users can directly connect to high-orbit satellites through mobile phones for real-time voice communication, which will greatly expand the range of communication services. However, in a high-orbit communication environment, due to limited link budget, only a low voice coding rate (such as 700 bps) can be used. In the case of using a low voice coding rate, the proportion of the effective load in the data packet transmitted through the air interface is actually very low, and the proportion of the header overhead is very high. In view of the problem that the header overhead is relatively high in the low voice coding rate scenario, the scheme in the embodiments of the present application can be used to reduce the header overhead, thereby improving the transmission efficiency of effective data.

[0054] The data transmission method, device, communication device and readable storage medium provided by the embodiments of the present application will be described in detail in combination with the drawings and some embodiments and application scenarios.

[0055] Please refer to FIG. 2, which is a flowchart of a data transmission method provided by an embodiment of the present application. The method is executed by a first node, as shown in FIG. 2, and includes the following steps:

[0056] Step 21: The first node sends the first data packet to the second node.

[0057] In the embodiments of the present application, the first node is specifically a data sending end, or a header compression end, or a compression entity / module / unit / processor in the data sending end, or a header processing entity / module / unit / processor in the data sending end, etc. The second node is specifically a data receiving end, or a header decompression end, or a decompression entity / module / unit / processor in the data receiving end, or a header processing entity / module / unit / processor in the data sending end, etc. For example, the first node can be a terminal, and correspondingly, the second node is a network node (or network side device); or the first node can be a network node, and correspondingly, the second node is a terminal. For example, the network node mentioned above can be a base station.

[0058] It should be noted that before the first node sends the first data packet to the second node, the network enables or starts the header compression function (or header reduction function, or header optimization function). For example, before the first node (e.g., a terminal) sends the first data packet to the second node (e.g., a base station), the network (e.g., a base station) configures the terminal to enable or start the header compression function. That is, in the case that the terminal is configured and starts the header compression function, the terminal can send the first data packet to the base station. As another example, before the first node (e.g., a base station) sends the first data packet to the second node (e.g., a terminal), the network (e.g., a base station) configures the terminal to enable or start the header compression function. That is, in the case that the terminal is configured and starts the header compression function, the base station can send the first data packet to the terminal. Correspondingly, the terminal will perform header compression related processing, for example, receiving the first data packet, storing the static field information carried by the first data packet, etc. In addition, it should be noted that the network enabling or starting the header compression function mentioned above can be starting only the uplink header compression function, or starting only the downlink header compression function, or starting both the uplink and downlink header compression functions.

[0059] Optionally, the first data packet includes the static field information of the header, which can be used to provide the static field information of the header corresponding to the voice service data, so that the data packet for subsequent user plane transmission can not need to carry the static field information of the header, but restore the corresponding static field information of the header based on the static field information of the header included in the first data packet, thereby reducing the header overhead.

[0060] Optionally, the static field information of the header can include at least one of the following:

[0061] (1) the static field information of the RTP header;

[0062] Optionally, the static field information of the RTP header can include value information of RTP static fields. The RTP static fields can include at least one of the following: RTP version field V, padding indication field P, extension header flag field E, payload type field, synchronization source identification field SSRC, and count of contributing source identification field CSRC Counter.

[0063] For example, for satellite voice service, the value of the extension header flag field E is 0. That is, for satellite voice service, the RTP extension header field is not used by default.

[0064] For example, for satellite voice service, the value of the payload type field is 101.

[0065] For example, for satellite voice service, the value of the count of contributing source identification field CSRC Counter is 0. That is, for satellite voice service, the mixer is not used by default. Further, when the value of the count of contributing source identification field CSRC Counter is 0, the CSRC field is not included in the RTP protocol header by default.

[0066] (2) Static field information of the UDP header;

[0067] Optionally, the static field information of the UDP header can include value information of UDP static fields. The UDP static fields can include at least one of the following: source port number field source port, destination port number field destination port, and length field Length.

[0068] (3) Static field information of the IP header.

[0069] Optionally, the static field information of the IP header can include value information of IP static fields. The IP static field information can include any one of the following:

[0070] (I) IPv4 static field information; for example, the IPv4 static field information includes value information of IPv4 static fields. The IPv4 static fields can include at least one of the following: IP version field V, IP header length field header Length, type of service field type of service, packet length field packet length, fragment offset field fragment offset, time to live field time to live, protocol field protocol, source address field source address, and destination address field destination address.

[0071] For example, for satellite voice service, the value of the type of service field can be a fixed value.

[0072] For example, for satellite voice service, the data packet can be sampled at a fixed time interval, and the size of each sampled data packet can be a fixed value. Therefore, the values of the IP header length and IP packet length fields can be fixed values.

[0073] For example, for satellite voice service with low coding rate, the value of the fragment offset field is 0. That is, for satellite voice service with low coding rate, the default is no fragmentation.

[0074] (II) IPv6 static field information; for example, the IPv6 static field information includes value information of an IPv6 static field. The IPv6 static field can include at least one of the following: IP version field V, traffic class field Traffic class, flow label field flow label, payload length field payload length, next header field next header, hop limit field Hop limit, source address field source address, and destination address field destination address.

[0075] For example, if it is specified that no extension header is used for satellite voice service, the value of the next header field next header is a fixed value during the life cycle of the satellite voice service.

[0076] It should be noted that the scheme of the present application can be used to process or compress a single type of header, such as only processing the RTP header, or the UDP header, or the IP header. The scheme of the present application can also be used to process or compress multiple types of headers, such as any combination of the RTP header, the UDP header, and the IP header. For example, for non-IP data transmission, there can be only the RTP header, and the scheme of the present application can be used to process data with only the RTP header. As another example, for data including the RTP header, the UDP header, and the IP header, the scheme of the present application can be used to process only the RTP header (such as compressing only the static fields of the RTP header, and optionally negotiating only the dynamic field information of the RTP header), or can be used to process at least two of the RTP header, the UDP header, and the IP header. The specific processing method can be selected based on the specific situation.

[0077] In addition, it should be noted that in a conventional robust header compression (ROHC) mechanism, after being processed by the ROHC protocol, all data packets need to be additionally added with ROHC related protocol fields, such as an ROHC context ID, an ROHC CRC, an ROHC profile ID, and the like. These information fields usually increase about 3 bytes. That is, even in the initial flush state of the ROHC (i.e., a full transmission data packet, which can be understood as a case without compressed header), about 3 bytes are additionally increased. In the method of the present application, however, these information fields can not be added, and thus the overhead is smaller compared with the ROHC scheme.

[0078] Through the scheme of the embodiments of the present application, the static field information of the header can be transmitted in advance or only part of the data packets can transmit the static field information of the header, so that the data packets transmitted in the subsequent user plane can not carry the static field information of the header, but recover the static field information of the corresponding header based on the static field information of the header transmitted in advance or acquired in advance, thereby reducing the header overhead and improving the transmission efficiency of the effective data.

[0079] In the embodiments of the present application, the static field information of the header can be transmitted or transmitted in advance through the control plane (such as control plane signaling) or the user plane (such as user plane data packets or user plane control packets).

[0080] Optionally, the sending of the first data packet to the second node can include:

[0081] The first node sends the first data packet to the second node through control plane signaling or user plane signaling. In this way, the static field information of the header can be provided through the control plane or the user plane.

[0082] Optionally, the control plane signaling is a radio resource control (RRC) message, and / or the user plane signaling is a user plane control packet.

[0083] In an optional implementation, when the static field information of the header is transmitted through the control plane signaling, the first data packet can be transmitted through a first signaling radio bearer (SRB), and the static field information of the header is used to provide the static field information of the header corresponding to the voice service data. The control plane signaling can be an RRC message. For example, the control plane signaling can be a downlink RRC message, such as an RRC reconfiguration message. For example, the first node is a network node, and the second node is a terminal. The network node can provide the static field information of the header corresponding to the voice service data to the terminal through the RRC reconfiguration message. Additionally, the static field information of the header is associated with (for example, through a DRB ID) a first data radio bearer (DRB), and the first data radio bearer is used to carry the voice service data. For example, when the static field information of the header is provided in the RRC reconfiguration message, the radio data bearer information associated with the static field information of the header, such as the DRB ID information, is additionally provided. As another example, the control plane signaling can be an uplink RRC message. For example, the first node is a terminal, and the second node is a network node. The terminal can provide the static field information of the header corresponding to the voice service data to the network node through the RRC message.

[0084] In another optional implementation, when the static field information of the header is transmitted through the user plane, the user plane control packet can be a PDCP control packet, such as a PDCP control PDU. Further, the first data packet belongs to a first data radio bearer, and the first data radio bearer is used to carry the voice service data.

[0085] In another optional implementation, when the static field information of the header is transmitted through the user plane, the static field information of the header can be carried through a user plane data packet. For example, the user plane data packet can be a PDCP data packet, such as a PDCP data PDU. The user plane data (such as a PDCP data PDU) can only carry the header information (such as the static field information of the header). As another example, the user plane data can also carry service data (such as voice service data).

[0086] Optionally, for the information field of the header, the first data packet can only include the static field information of the header. That is, the first data packet does not include the dynamic field information of the header.

[0087] Optionally, the dynamic field information of the header can include at least one of the following:

[0088] (a) dynamic field information of the RTP header; for example, the dynamic field information of the RTP header can comprise value information of an RTP dynamic field; the RTP dynamic field can comprise at least one of the following: an RTP sequence number field, an RTP timestamp field, an RTP marker bit field, etc.; in some instances (such as a scenario using a mixer), the RTP dynamic field can further comprise at least one of the following: a contribution source count field CSRC Counter, a contribution source identification field CSRC, etc.

[0089] (b) dynamic field information of the UDP header; for example, the dynamic field information of the UDP header can comprise value information of a UDP dynamic field; the UDP dynamic field can comprise a UDP check field, etc.

[0090] (c) dynamic field information of the IP header; for example, the dynamic field information of the IP header can comprise value information of an IP dynamic field; the IP dynamic field can comprise an IP identification field, etc.

[0091] It should be noted that the static field in the embodiments of the present application refers to a header field whose value remains fixed in the life cycle of a voice service (such as a satellite voice service), and the dynamic field in the embodiments of the present application refers to a header field whose value changes in the life cycle of a voice service (such as a satellite voice service).

[0092] Optionally, the first data packet can comprise dynamic field negotiation information of the header in addition to the static field information of the header, and the dynamic field negotiation information of the header is used to determine the related content of the dynamic field in the data packet of subsequent user plane transmission. The dynamic field negotiation information of the header can comprise at least one of the following:

[0093] 1) negotiation information of an RTP dynamic field;

[0094] Optionally, the negotiation information of the RTP dynamic field can comprise at least one of the following:

[0095] negotiation information of an RTP sequence number field; wherein the negotiation information of the RTP sequence number field can comprise at least one of the following: mapping relationship information of an RTP sequence number and a PDCP sequence number, function information enabling derivation of the RTP sequence number based on the PDCP sequence number. For example, the PDCP sequence number can be a PDCP COUNT or a PDCP SN. For example, the RTP sequence number can be acquired based on the PDCP sequence number (such as a PDCP COUNT), for example, the value of the RTP sequence number is equal to the value of the low 16 bits of the PDCP COUNT.

[0096] negotiation information of the RTP timestamp field; wherein the negotiation information of the RTP timestamp field can comprise time increment step information. In addition, the negotiation information of the RTP timestamp field can also comprise initial timestamp information. It can be understood that the initial timestamp information can correspond to the timestamp of the first data packet.

[0097] For the convenience of understanding, in the voice service scenario, the voice service data is periodically generated, and therefore the time difference of the RTP timestamps corresponding to the continuously generated voice service data packets is a fixed value. Assuming that the time difference of the RTP timestamps corresponding to the continuous data packets is 20s, the continuous data packets comprise #1 RTP data packet, #2 RTP data packet, #3 RTP data packet, and so on, and the timestamp of the #1 RTP data packet is 12:00:00, then the timestamp of the #2 RTP data packet is 12:00:20, the timestamp of the #3 RTP data packet is 12:00:40, and so on. That is, if the timestamp information corresponding to a data packet is known, the timestamp information corresponding to another data packet can be derived based on the number difference between the two data packets and the time increment step information.

[0098] 2) negotiation information of the UDP dynamic field;

[0099] Optionally, the negotiation information of the UDP dynamic field can comprise negotiation information of the UDP check field. The negotiation information of the UDP check field can comprise any one of the following: information enabling the UDP layer check function, information disabling the UDP layer check function.

[0100] For example, the negotiation information of the UDP check field can be a presence indication bit of the UDP check field. For example, if the presence indication bit of the UDP check field is set to 1, it indicates that the corresponding service data packet carries the UDP check field; and if the presence indication bit of the UDP check field is set to 0, it indicates that the corresponding service data packet does not carry the UDP check field. The service data packet is transmitted through a radio data bearer DRB.

[0101] For another example, the negotiation information of the UDP check field can be an enabling indication bit of the UDP check field. For example, if the enabling indication bit of the UDP check field is set to 1, the check function of the UDP layer is enabled, that is, the corresponding service data packet needs to carry the UDP check field; and if the enabling indication bit of the UDP check field is set to 0, the check function of the UDP layer is disabled, that is, the corresponding service data packet does not carry the UDP check field.

[0102] 3) negotiation information of the IP dynamic field.

[0103] Optionally, the negotiation information of the IP dynamic field can comprise negotiation information of an IP Identification field. The negotiation information of the IP Identification field can comprise at least one of the following: allocation rule information of the IP Identification field, allocation step information of the IP Identification field, function information enabling derivation of the IP Identification field based on a PDCP sequence number, and mapping relationship information between the IP Identification field and the PDCP sequence number.

[0104] Optionally, the negotiation information of the IP Identification field can be negotiation information of an IPv4 Identification field. For example, the negotiation information of the IPv4 Identification field can be an existence indication bit of the IPv4 Identification field. For example, if the existence indication bit of the IPv4 Identification field is set to 1, the IPv4 Identification field is carried in the corresponding service data packet. For another example, the negotiation information of the IPv4 Identification field can also be allocation mode information of an IPv4 Identification value, wherein the allocation mode information comprises at least one of a start value and an allocation step.

[0105] For example, the allocation mode information of the IPv4 Identification value can be sequential allocation or random allocation. In the case of sequential allocation, the allocation rule can be configured in advance. In the case of knowing the allocation rule, the IPv4 Identification value can be derived based on the predetermined rule, and therefore the service data packet does not need to always carry the IPv4 Identification field. In the case of random allocation, the value of the field has no regularity, and therefore the service data packet needs to always carry the IPv4 Identification field.

[0106] For example, the allocation mode information of the IPv4 Identification value can be allocation starting from 0 and an allocation step of 1.

[0107] Optionally, before the first node sends the first data packet to the second node, the network node can configure a header overhead negotiation function for the terminal, or the network node enables the header overhead negotiation function. Based on the enabled header overhead negotiation function, the terminal can send the first data packet to the network node.

[0108] In the embodiments of the present application, when transmitting the first data packet through the user plane, the first data packet can include indication information about the dynamic field in addition to the static field information of the header, such as indicating whether the first data packet and / or the second data packet carries certain dynamic field, so as to accurately decompress the first data packet and / or the second data packet according to the indication information. The second data packet can be understood as a service data packet, such as a PDCP data packet, which is sent after the first data packet. Alternatively, the first data packet can further include at least one of the following:

[0109] a) first indication information, which is used to indicate whether the first data packet and / or the second data packet carries an IP identification field; for example, in the first data packet, when the value of the first indication information is set to 0, it is used to indicate that the first data packet and / or the second data packet does not carry the IP identification field; and when the value of the first indication information is set to 1, it is used to indicate that the first data packet and / or the second data packet carries the IP identification field;

[0110] b) second indication information, which is used to indicate whether the first data packet and / or the second data packet carries a UDP check field; for example, in the first data packet, when the value of the second indication information is set to 0, it is used to indicate that the first data packet and / or the second data packet does not carry the UDP check field; and when the value of the second indication information is set to 1, it is used to indicate that the first data packet and / or the second data packet carries the UDP check field; for example, for satellite voice service, the first data packet does not include the second indication information in the case of always disabling the UDP check function;

[0111] c) third indication information, which is used to indicate the value of the RTP mark field; for example, in the first data packet, the third indication information has no meaning, i.e., the second node ignores the indication information;

[0112] d) fourth indication information, which is used to indicate whether the first data packet and / or the second data packet carries a static field; the static field can include at least one of the following: RTP static field, UDP static field, IP static field; for example, in the first data packet, when the value of the fourth indication information is set to 1, it is used to indicate that the first data packet and / or the second data packet carries the static field; and when the value of the fourth indication information is set to 0, it is used to indicate that the first data packet and / or the second data packet does not carry the static field;

[0113] e) fifth indication information, used for indicating whether the first data packet and / or the second data packet carries an RTP timestamp field; for example, in the first data packet, when the value of the fifth indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries an RTP timestamp field; and when the value of the fifth indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry an RTP timestamp field;

[0114] f) sixth indication information, used for indicating whether the first data packet and / or the second data packet carries an RTP sequence number field; for example, in the first data packet, when the value of the sixth indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries an RTP sequence number field; and when the value of the sixth indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry an RTP sequence number field.

[0115] For example, at least one of the above a) to f) can be carried by a PDCP header.

[0116] In an optional embodiment, the first data packet is a PDCP control packet. In this embodiment, a packet type field (such as a PDCP PDU Type field, an existing information field in the existing protocol) of the first data packet is used for indicating that the first data packet is a PDCP control packet carrying the static field of the header. For example, when the PDCP PDU Type field is set as 101, it indicates that the first data packet is a PDCP control packet carrying the static field of the header. In addition, it should be noted that in the case where the first data packet is a PDCP control packet, the first data packet can not include the first indication information to the sixth indication information described above; in this embodiment, the first data packet is used for transmitting the static field information of the header, and the second data packet described below is used for transmitting the dynamic field information of the header and the payload (such as voice service data). The advantage of this mode is that the design of the packet format of the newly introduced first data packet is relatively simple, but the packet format of the second data packet needs to include the indication information field indicating whether there is dynamic field. In another embodiment, the first data packet can include the first indication information to the sixth indication information described above; in this embodiment, these indication information are used for indicating whether the subsequent PDCP data packet (such as the second data packet described below) carries dynamic field information (such as a UDP check field). In this case, the second data packet can not carry the indication information indicating the dynamic field information of the header. The advantage of this embodiment is that the packet format of the second data packet can adopt the existing packet format, that is, a new PDCP data packet format is not introduced.

[0117] In another alternative implementation, the first data packet is a PDCP data packet. In this implementation, the first data packet can further carry dynamic field information of the header. The dynamic field information of the header can include one or more of an IP identification field, a UDP check field, and an RTP marker field. Further, the first data packet can further carry a payload (e.g., voice service data).

[0118] Optionally, when the first node transmits the first data packet, it can transmit one or N (N > 1) first data packets to ensure that the second node can obtain the information carried in the first data packet. For example, the N can be agreed upon by a protocol, configured by a network, or determined by the first node based on implementation.

[0119] Optionally, when the first data packet is transmitted through control plane signaling SRB (e.g., an RRC message), the above a) to f) can be used to indicate whether the second data packet (e.g., transmitted through a DRB) has corresponding dynamic field information. When the first data packet is transmitted through a user plane control packet (e.g., through a DRB, such as a PDCP control PDU), the above a) to f) can be used to indicate whether the second data packet (e.g., transmitted through a DRB) has corresponding dynamic field information. When the first data packet is transmitted through a user plane data packet (e.g., through a DRB, such as a PDCP data PDU), the above a) to f) can be used to indicate whether the first data packet (e.g., transmitted through a DRB) itself has corresponding dynamic field information.

[0120] Optionally, after the first node transmits the first data packet to the second node, the data transmission method in this embodiment further includes:

[0121] The first node receives feedback information transmitted by the second node, and the feedback information is used to feed back that the second node has successfully stored the static field information of the header. For example, after receiving the first data packet, the second node can store the static field information of the header based on the first data packet, and transmit the feedback information to the first node. In this way, the first node can know that the second node has successfully stored the static field information of the header.

[0122] For example, the feedback information can be carried by a PDCP control packet. Further, the feedback information only contains PDCP header information. For example, a packet type field (e.g., PDCP PDU Type field, an information field already existing in the existing protocol) in the PDCP header information is used to indicate that the PDCP control packet is a PDCP control packet for feeding back the static field information of the successfully stored header. By this embodiment, the feedback information sent by the second node can realize only one byte of overhead, which is relatively small. In a traditional robust header compression (ROHC) scheme, the feedback information needs to carry context identification information (e.g., context ID, occupying 1-2 bytes), and usually needs 2-3 bytes. Therefore, compared with the ROHC mechanism, the present scheme is more concise and has smaller feedback overhead. It should be noted that in a satellite voice service scenario, such as a high-orbit satellite communication environment, the communication capacity is usually limited, and the present scheme can realize feedback confirmation with smaller overhead, and therefore has more advantages.

[0123] Optionally, in the case that the first data packet includes dynamic field negotiation information of the header, the feedback information can also be used to feed back the dynamic field negotiation information of the successfully stored header by the second node. Further, the feedback information only contains PDCP header information. For example, a packet type field (e.g., PDCP PDU Type field, an information field already existing in the existing protocol) in the PDCP header information is used to indicate that the corresponding PDCP control packet is a PDCP control packet for feeding back the dynamic field negotiation information of the successfully stored header.

[0124] Optionally, the PDCP control packet for feeding back the static field information of the successfully stored header and the PDCP control packet for feeding back the dynamic field negotiation information of the successfully stored header can be different PDCP control packets, or can be the same PDCP control packet. For example, in the case of using different PDCP control packets, the packet type field can be set to different field values, respectively used for feeding back the static field information of the successfully stored header and the dynamic field negotiation information of the successfully stored header. In the case of using the same PDCP control packet, the packet type field can be set to the same value. In this case, in one embodiment, the static field information of the successfully stored header and the dynamic field negotiation information of the successfully stored header are simultaneously fed back by the above PDCP control packet. In another example, the above PDCP control packet can also carry an indication bit, such as a two-bit indication bit, respectively used for feeding back the static field information of the successfully stored header and the dynamic field negotiation information of the successfully stored header.

[0125] For example, when the first data packet is carried by an RRC reconfiguration message, the feedback information can be sent by an RRC reconfiguration complete message. The feedback information can be one bit. As another example, when the first data packet is carried by an uplink RRC message, the feedback information can be sent by a downlink RRC message. The feedback information can be one bit. In this embodiment, the uplink RRC message and the downlink RRC message can be newly introduced RRC messages used for negotiating the static field information of the packet and / or the configuration information of the dynamic field.

[0126] Optionally, the first node can continuously send the first data packet before the second node feeds back that it has successfully stored the static field information and / or the negotiated configuration information of the dynamic field. That is, the first node can start sending a second data packet after receiving the feedback from the second node that it has successfully stored the static field information and / or the negotiated configuration information of the dynamic field.

[0127] Optionally, the first node can also receive request information or feedback information sent by the second node. Based on the request information or the feedback information, the first node can send the first data packet again, which carries the static field information of the packet header. It can be understood that the request information or the feedback information can be understood as the second node requesting the first node to retransmit or resend the static field information of the packet header.

[0128] It should be noted that the values of some static fields can be agreed upon by a protocol or preconfigured. In this case, the first node can not send these static field information to the second node. In the second node, the stored static field information of the packet header includes the static field information sent by the first node and the static field information agreed upon by the protocol or preconfigured.

[0129] Optionally, after sending the first data packet to the second node, the data transmission method in this embodiment further includes:

[0130] The first node sends a second data packet to the second node, and the second data packet does not include the static field information of the packet header. The second data packet can be understood as a service data packet sent after the first data packet. For example, the second data packet is transmitted by the first data radio bearer. In this way, after receiving the second data packet, the second node can restore the static field information of the corresponding packet header of the second data packet according to the stored static field information of the packet header, thereby reducing the overhead of the packet header.

[0131] Optionally, for some regular dynamic fields, such as RTP timestamp, IP identification field, etc., dynamic update is also possible. It can be understood that in the case of dynamic update, the corresponding information field is carried in the second data packet. For example, in the case of enabling derivation of RTP timestamp information based on PDCP sequence number, it is generally not necessary for each data packet to carry RTP timestamp. However, in some cases, such as after a period of voice service interruption, the second data packet can carry RTP timestamp information for the receiving end to update the latest dynamic field information.

[0132] Optionally, the second data packet comprises dynamic field information of the header. That is, the second data packet only transmits dynamic field information of the header, and does not transmit static field information of the header, that is, only the static field information of the header is compressed, and all the dynamic field information of the header is not compressed. In this case, the static field information of the header can be pre-set or transmitted in advance by the first data packet, and the dynamic field information does not need to be negotiated or indicated by the first data packet.

[0133] Optionally, the second data packet does not comprise at least one of the RTP sequence number field and the RTP timestamp field. That is, the second data packet does not transmit static field information of the header, and does not transmit the RTP sequence number field and / or the RTP timestamp field, and only transmits other dynamic fields except the RTP sequence number field and / or the RTP timestamp field, that is, the static field information of the header and the RTP sequence number field and / or the RTP timestamp field are compressed, and other dynamic fields are not compressed. In this case, the static field information of the header can be pre-set or transmitted in advance by the first data packet, the related information of the RTP sequence number field and / or the RTP timestamp field can be negotiated or indicated by the first data packet, and other dynamic fields do not need to be negotiated or indicated by the first data packet.

[0134] Optionally, the second data packet is a PDCP data packet.

[0135] Optionally, in order to accurately decompress the second data packet, the second data packet can further comprise at least one of the following:

[0136] g) seventh indication information for indicating whether the second data packet carries an IP identification field; for example, in the second data packet, when the value of the seventh indication information is set to 0, it is used to indicate that the second data packet does not carry an IP identification field; and when the value of the seventh indication information is set to 1, it is used to indicate that the second data packet carries an IP identification field;

[0137] h) eighth indication information, used for indicating whether the second data packet carries a UDP check field; for example, in the second data packet, when the value of the eighth indication information is set to 0, it is used for indicating that the second data packet does not carry a UDP check field; and when the value of the eighth indication information is set to 1, it is used for indicating that the second data packet carries a UDP check field; for another example, for satellite voice service, the eighth indication information is not included in the second data packet in the case of always disabling the UDP check function;

[0138] i) ninth indication information, used for indicating the value of an RTP mark field;

[0139] j) tenth indication information, used for indicating whether the second data packet carries a static field; the static field includes at least one of the following, for example: an RTP static field, a UDP static field, and an IP static field; for example, in the second data packet, when the value of the tenth indication information is set to 1, it is used for indicating that the second data packet carries a static field; and when the value of the tenth indication information is set to 0, it is used for indicating that the second data packet does not carry a static field;

[0140] k) eleventh indication information, used for indicating whether the second data packet carries an RTP timestamp field; for example, in the second data packet, when the value of the eleventh indication information is set to 1, it is used for indicating that the second data packet carries an RTP timestamp field; and when the value of the eleventh indication information is set to 0, it is used for indicating that the second data packet does not carry an RTP timestamp field;

[0141] m) twelfth indication information, used for indicating whether the second data packet carries an RTP sequence number field; for example, in the second data packet, when the value of the twelfth indication information is set to 1, it is used for indicating that the second data packet carries an RTP sequence number field; and when the value of the twelfth indication information is set to 0, it is used for indicating that the second data packet does not carry an RTP sequence number field.

[0142] By means of the above g) to m), the second node can accurately decompress the second data packet.

[0143] Referring to FIG. 3, FIG. 3 is a flowchart of a data transmission method provided by an embodiment of the present application, the method is executed by a second node, as shown in FIG. 3, the method includes the following steps:

[0144] Step 31: The second node receives a first data packet sent by a first node.

[0145] In the embodiments of the present application, the first node is specifically a data sending end, or a header compression end, or a compression entity / module / unit / processor in the data sending end, or a header processing entity / module / unit / processor in the data sending end, etc. The second node is specifically a data receiving end, or a header decompression end, or a decompression entity / module / unit / processor in the data receiving end, or a header processing entity / module / unit / processor in the data receiving end, etc. For example, the first node can be a terminal, and correspondingly, the second node is a network node (or referred to as a network side device); or the first node can be a network node, and correspondingly, the second node is a terminal. For example, the network node mentioned above can be a base station.

[0146] Optionally, the first data packet includes static field information of a header, and the static field information of the header can be used to provide static field information of a header corresponding to voice service data, so that a data packet for subsequent user plane transmission can not need to carry the static field information of the header, but can restore the corresponding static field information of the header based on the static field information of the header included in the first data packet, thereby reducing header overhead.

[0147] Optionally, the static field information of the header can include at least one of the following:

[0148] (1) Static field information of an RTP header; optionally, the static field information of the RTP header can include value information of an RTP static field. The RTP static field can include at least one of an RTP version field V, a padding indication field P, an extension header flag field E, a payload type field, a synchronization source identification field SSRC, and a contribution source identification counter field CSRC Counter.

[0149] (2) Static field information of a UDP header; optionally, the static field information of the UDP header can include value information of a UDP static field. The UDP static field can include at least one of a source port number field source port, a destination port number field destination port, and a length field Length.

[0150] (3) Static field information of an IP header.

[0151] Optionally, the static field information of the IP header can include value information of an IP static field. The IP static field information can include any one of the following:

[0152] (I) IPv4 static field information; for example, the IPv4 static field information includes value information of an IPv4 static field. The IPv4 static field can include at least one of an IP version field V, an IP header length field header Length, a service type field type of service, a packet length field packet length, a fragment offset field fragment offset, a time to live field time to live, a protocol field protocol, a source address field source address, and a destination address field destination address.

[0153] (II) IPv6 static field information; for example, the IPv6 static field information includes value information of an IPv6 static field. The IPv6 static field can include at least one of an IP version field V, a traffic class field Traffic class, a flow label field flow label, a payload length field payload length, a next header field next header, a hop limit field Hop limit, a source address field source address, and a destination address field destination address.

[0154] Through the scheme of the embodiments of the present application, the static field information of the header can be transmitted in advance or only part of the data packet can transmit the static field information of the header, so that the data packet transmitted in the subsequent user plane can not carry the static field information of the header, but restore the corresponding static field information of the header based on the static field information of the header transmitted in advance or obtained in advance, thereby reducing the header overhead and improving the transmission efficiency of data.

[0155] In the embodiments of the present application, the static field information of the header can be transmitted in advance through the control plane or the user plane. The receiving of the first data packet sent by the first node can include:

[0156] The second node receives the first data packet sent by the first node through control plane signaling or user plane signaling. In this way, the static field information of the header can be provided through the control plane or the user plane.

[0157] Optionally, the control plane signaling is a radio resource control RRC message, and / or the user plane signaling is a user plane control packet. Compared with the traditional ROHC scheme (such as transmitting static field information through user data), the control plane scheme (such as through control plane signaling SRB or user plane control packet, such as control PDU) can ensure that the data receiving end completes the storage of the static field of the header before the voice call, and can avoid transmitting the static field information when the voice service starts, thereby accelerating the voice call.

[0158] Optionally, for the information field of the header, the first data packet can only include the static field information of the header. That is, the first data packet does not include the dynamic field information of the header.

[0159] Optionally, the dynamic field information of the header can include at least one of the following:

[0160] (a) the dynamic field information of the RTP header; for example, the dynamic field information of the RTP header can include the value information of the RTP dynamic field; the RTP dynamic field can include at least one of the following: the RTP sequence number field, the RTP timestamp field, etc.; in some instances (such as the scenario of using a mixer), the RTP dynamic field can also include at least one of the following: the contribution source count field CSRC Counter, the contribution source identification field CSRC, etc.

[0161] (b) the dynamic field information of the UDP header; for example, the dynamic field information of the UDP header can include the value information of the UDP dynamic field; the UDP dynamic field can include the UDP check field, etc.

[0162] (c) the dynamic field information of the IP header; for example, the dynamic field information of the IP header can include the value information of the IP dynamic field; the IP dynamic field can include the IP identification field, etc.

[0163] It should be noted that the static field in the embodiments of the present application refers to the header field whose value remains fixed in the life cycle of the voice service (such as satellite voice service), and the dynamic field in the embodiments of the present application refers to the header field whose value changes in the life cycle of the voice service (such as satellite voice service).

[0164] Optionally, in addition to including the static field information of the header, the first data packet can also include the dynamic field negotiation information of the header, which is used to determine the related content of the dynamic field in the data packet of the subsequent user plane transmission. The dynamic field negotiation information of the header can include at least one of the following:

[0165] 1) the negotiation information of the RTP dynamic field;

[0166] Optionally, the negotiation information of the RTP dynamic field can include at least one of the following:

[0167] - negotiation information of an RTP sequence number field; wherein the negotiation information of the RTP sequence number field can comprise at least one of the following: mapping relationship information of an RTP sequence number and a PDCP sequence number, function information enabling derivation of the RTP sequence number based on the PDCP sequence number. For example, the PDCP sequence number can be a PDCP COUNT or a PDCP SN. For example, the RTP sequence number can be acquired based on the PDCP sequence number (e.g., PDCP COUNT), for example, the value of the RTP sequence number is equal to the value of the lower 16 bits of the PDCP COUNT.

[0168] - negotiation information of an RTP timestamp field; wherein the negotiation information of the RTP timestamp field can comprise time increment step information. In addition, the negotiation information of the RTP timestamp field can also comprise initial timestamp information. It can be understood that the initial timestamp information can correspond to the timestamp of a first data packet.

[0169] For ease of understanding, in a voice service scenario, voice service data is periodically generated, and therefore the time difference of the RTP timestamps corresponding to the continuously generated voice service data packets is a fixed value. Assuming that the time difference of the RTP timestamps corresponding to the continuous data packets is 20s, the continuous data packets include #1 RTP data packet, #2 RTP data packet, #3 RTP data packet,..., and the timestamp of the #1 RTP data packet is 12:00:00, then the timestamp of the #2 RTP data packet is 12:00:20, the timestamp of the #3 RTP data packet is 12:00:40, and so on. That is, if the timestamp information corresponding to a data packet is known, the timestamp information corresponding to another data packet can be derived based on the number difference between the two data packets and the time increment step information.

[0170] 2) negotiation information of a UDP dynamic field;

[0171] Optionally, the negotiation information of the UDP dynamic field can comprise negotiation information of a UDP check field. The negotiation information of the UDP check field can comprise any one of the following: information enabling a UDP layer check function, information disabling the UDP layer check function.

[0172] For example, the negotiation information of the UDP check field can be a presence indication bit of the UDP check field. For example, if the presence indication bit of the UDP check field is set to 1, it can be indicated that the UDP check field is carried in the corresponding service data packet; and if the presence indication bit of the UDP check field is set to 0, it can be indicated that the UDP check field is not carried in the corresponding service data packet. The service data packet is transmitted through a radio data bearer DRB.

[0173] For example, the negotiation information of the UDP check field can be an enabling indication bit of the UDP check field. For example, if the enabling indication bit of the UDP check field is set to 1, the check function of the UDP layer is enabled, i.e., the corresponding service data packet needs to carry the UDP check field; and if the enabling indication bit of the UDP check field is set to 0, the check function of the UDP layer is disabled, i.e., the corresponding service data packet does not carry the UDP check field.

[0174] 3) negotiation information of the IP dynamic field.

[0175] Optionally, the negotiation information of the IP dynamic field can include negotiation information of an IP identification field. The negotiation information of the IP identification field can include at least one of the following: allocation rule information of the IP identification field, allocation step information of the IP identification field, function information enabling derivation of the IP identification field based on a PDCP sequence number, and mapping relationship information of the IP identification field and the PDCP sequence number.

[0176] Optionally, the negotiation information of the IP identification field can be negotiation information of an IPv4 identification field. For example, the negotiation information of the IPv4 identification field can be an existing indication bit of the IPv4 identification field. For example, if the existing indication bit of the IPv4 identification field is set to 1, the corresponding service data packet carries the IPv4 identification field. For example, the negotiation information of the IPv4 identification field can also be allocation mode information of an IPv4 identification value, where the allocation mode information includes at least one of a start value and an allocation step.

[0177] In the embodiment, when the first data packet is transmitted through the user plane, the first data packet can include not only the static field information of the header, but also indication information about the dynamic field, such as indication of whether the first data packet and / or the second data packet carries some dynamic field, so as to accurately decompress the first data packet and / or the second data packet according to the indication information. The second data packet can be understood as a service data packet, such as a PDCP data packet, sent after the first data packet. Optionally, the first data packet can further include at least one of the following:

[0178] a) first indication information, used for indicating whether the first data packet and / or the second data packet carries an IP identification field; for example, in the first data packet, when the value of the first indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry an IP identification field; and when the value of the first indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries an IP identification field;

[0179] b) second indication information, used for indicating whether the first data packet and / or the second data packet carries a UDP check field; for example, in the first data packet, when the value of the second indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry a UDP check field; and when the value of the second indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries a UDP check field; for another example, for satellite voice service, the first data packet does not include the second indication information in the case of always disabling the UDP check function;

[0180] c) third indication information, used for indicating the value of an RTP mark field; for example, in the first data packet, the third indication information has no meaning, i.e., the second node ignores the indication information;

[0181] d) fourth indication information, used for indicating whether the first data packet and / or the second data packet carries a static field; the static field may include at least one of the following: an RTP static field, a UDP static field, and an IP static field; for example, in the first data packet, when the value of the fourth indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries a static field; and when the value of the fourth indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry a static field;

[0182] e) fifth indication information, used for indicating whether the first data packet and / or the second data packet carries an RTP timestamp field; for example, in the first data packet, when the value of the fifth indication information is set as 1, it is used for indicating that the first data packet and / or the second data packet carries an RTP timestamp field; and when the value of the fifth indication information is set as 0, it is used for indicating that the first data packet and / or the second data packet does not carry an RTP timestamp field;

[0183] f) the sixth indication information is used to indicate whether the first data packet and / or the second data packet carries an RTP sequence number field; for example, in the first data packet, when the value of the sixth indication information is set to 1, it is used to indicate that the first data packet and / or the second data packet carries an RTP sequence number field; and when the value of the sixth indication information is set to 0, it is used to indicate that the first data packet and / or the second data packet does not carry an RTP sequence number field.

[0184] Optionally, the data transmission method in the embodiments of the present application can further include at least one of the following:

[0185] - in the case where the first data packet is a PDCP data packet (such as carrying voice service data), the second node obtains the RTP sequence number corresponding to the first data packet according to the PDCP sequence number of the first data packet; for example, the PDCP sequence is PDCP COUNT, and the low 16 bits of the PDCP COUNT (such as a 32-bit variable) value corresponding to the first data packet is equal to the RTP sequence number corresponding to the first data packet. In the traditional ROHC mechanism, the ROHC compression entity and the ROHC decompression entity need to synchronize the RTP sequence number information, which is achieved by different ROHC packet types. In some use cases, such as high-orbit voice scenarios, due to poor link quality, the ROHC data packet for dynamically synchronizing the RTP sequence number information may be lost, which may cause the ROHC compression entity and the ROHC decompression entity to be misaligned for the RTP sequence number information, and further cause the compression state to degrade, i.e., the compression efficiency is low. In the case where the link quality is poor, the compression efficiency cannot be quickly recovered, which will cause the compression efficiency to be unstable. In the embodiments of the present application, the RTP sequence number is derived through the PDCP sequence number, which can avoid dynamically synchronizing the RTP sequence number information, and helps to maintain the stability of the compression efficiency.

[0186] - in a case that the first data packet is a PDCP data packet and the first data packet carries an RTP timestamp field, the second node stores RTP timestamp information in the RTP timestamp field. In a conventional ROHC mechanism, an ROHC compression entity and an ROHC decompression entity need to synchronize the RTP timestamp information, which is achieved by different ROHC packet types. In some use cases, such as a high orbit voice scenario, due to poor link quality, ROHC data packets dynamically synchronizing the RTP timestamp information can be lost, which can cause the ROHC compression entity and the ROHC decompression entity to be misaligned with respect to the RTP timestamp information, and further cause the compression state to degrade, i.e., the compression efficiency to be low. In a case of poor link quality, the compression efficiency cannot be quickly recovered, which will cause the compression efficiency to be unstable. In embodiments of the present application, the RTP timestamp is derived based on the PDCP sequence number, which can avoid dynamically synchronizing the RTP timestamp information, and help maintain the stability of the compression efficiency.

[0187] - in a case that the first data packet is a PDCP data packet (e.g., carrying voice service data) and the first data packet does not carry an RTP timestamp field, the second node obtains the RTP timestamp information corresponding to the first data packet based on the PDCP sequence number of the first data packet and the stored RTP timestamp information. For example, in a case that the first data packet does not carry the RTP timestamp information, the second node can obtain the RTP timestamp information corresponding to the first data packet based on the PDCP sequence number of the first data packet and predetermined time increment information. It should be noted that in a voice service scenario, voice service data is periodically generated, and therefore the time difference of the RTP timestamps corresponding to the continuously generated voice service packets is a fixed value. Assuming that the time difference of the RTP timestamps corresponding to the continuously generated data packets is 20s, the timestamp of an #1 RTP data packet is 12:00:00, the timestamp of an #2 RTP data packet is 12:00:20, the timestamp of an #3 RTP data packet is 12:00:40, and so on. Assuming that the RTP sequence number corresponding to the data packet received by the second node is #5, and the stored timestamp information (12:00:40) of the terminal is associated with the RTP sequence number #3, the second node can derive that the timestamp corresponding to the data packet with the RTP sequence number #5 is 12:01:20. In embodiments of the present application, the RTP timestamp is derived based on the PDCP sequence number, which can avoid dynamically synchronizing the RTP timestamp information, and help maintain the stability of the compression efficiency relative to the conventional ROHC mechanism.

[0188] - when the first data packet is a PDCP data packet and the first data packet does not carry an IP identification field, the second node obtains the IP identification information corresponding to the first data packet according to the PDCP sequence number of the first data packet. For example, the IP identification field is assigned starting from 0 with a step of 1, so that the IP identification corresponding to the #1 data packet is 0, the IP identification corresponding to the #1 data packet is 1, and so on. The IP identification corresponding to the first data packet can be obtained based on this rule. In the conventional ROHC mechanism, the ROHC compression entity and the ROHC decompression entity need to synchronize the IP identification information, which is achieved by different ROHC packet types. In some use cases, such as a high-orbit voice scenario, due to poor link quality, the ROHC data packet for dynamically synchronizing the IP identification information can be lost, which can cause the ROHC compression entity and the ROHC decompression entity to be misaligned with the IP identification information, and further cause the compression state to degrade, i.e., the compression efficiency is low. In the case of poor link quality, the compression efficiency cannot be quickly recovered, which will cause the compression efficiency to be unstable. In the embodiments of the present application, the IP identification is derived by the PDCP sequence number, which can avoid dynamically synchronizing the IP identification information, and helps to maintain the stability of the compression efficiency.

[0189] Optionally, after receiving the first data packet sent by the first node, the second node can store the static field information of the header, so as to decompress the service data packet received subsequently by using the static field information of the header, or recover the static field information corresponding to the service data packet received subsequently.

[0190] Optionally, the data transmission method further includes that the second node sends feedback information to the first node, and the feedback information is used to feed back that the second node has successfully stored the static field information of the header. In this way, the first node can know that the second node has successfully stored the static field information of the header. For example, before the second node successfully stores the static field information of the header, the second node does not send the above feedback information to the first node.

[0191] Optionally, the second node can also send request information or feedback information to the first node, and based on the request information or the feedback information, the first node can send the first data packet again, which carries the static field information of the header. It can be understood that the request information or the feedback information can be understood as the second node requesting the first node to retransmit or resend the static field information of the header.

[0192] Optionally, in the case that the first data packet comprises the dynamic field negotiation information of the header, the feedback information can also be used to feed back the dynamic field negotiation information of the header that the second node successfully stores.

[0193] Optionally, in the case that the first data packet comprises the dynamic field negotiation information of the header, the feedback information can also be used to feed back the dynamic field negotiation information of the header that the second node successfully stores.

[0194] Optionally, in the case that the first data packet is carried by the RRC reconfiguration message, the feedback information can be sent by the RRC reconfiguration completion message. As another example, in the case that the first data packet is carried by the uplink RRC message, the feedback information can be sent by the downlink RRC message. In this embodiment, the uplink RRC message and the downlink RRC message can be newly introduced RRC messages used to negotiate the static field information of the message and the configuration information of the dynamic field.

[0195] It should be noted that the values of some static fields can be agreed by the protocol. In this case, the first node can not send the static field information to the second node. While in the second node, the stored static field information of the header comprises the static field information sent by the first node and the static field information agreed by the protocol.

[0196] Optionally, after receiving the first data packet sent by the first node, the data transmission method in the embodiment of the present application can further comprise:

[0197] The second node receives the second data packet sent by the first node, and the second data packet does not comprise the static field information of the header. The second data packet can be understood as a service data packet sent after the first data packet. For example, the second data packet is transmitted by the first data radio bearer. In this way, after receiving the second data packet, the second node can restore the static field information of the header corresponding to the second data packet according to the stored static field information of the header, thereby reducing the header overhead.

[0198] Optionally, the second data packet is a PDCP data packet.

[0199] Optionally, the second data packet comprises dynamic field information of the header. That is, the second data packet only transmits the dynamic field information of the header, but not the static field information of the header, i.e. only the static field information of the header is compressed, and the dynamic field information of the header is not compressed. In this case, the static field information of the header can be preset or transmitted in advance by the first data packet, and the dynamic field information of the header does not need to be negotiated or indicated by the first data packet.

[0200] Optionally, the second data packet does not comprise at least one of the RTP sequence number field and the RTP timestamp field. That is, the second data packet does not transmit the static field information of the header, and does not transmit the RTP sequence number field and / or the RTP timestamp field, but only transmits other dynamic fields except the RTP sequence number field and / or the RTP timestamp field, i.e. the static field information of the header and the RTP sequence number field and / or the RTP timestamp field are compressed, and other dynamic fields are not compressed. In this case, the static field information of the header can be preset or transmitted in advance by the first data packet, the related information of the RTP sequence number field and / or the RTP timestamp field can be negotiated or indicated by the first data packet, and other dynamic fields do not need to be negotiated or indicated by the first data packet.

[0201] Optionally, in order to accurately decompress the second data packet, the second data packet can further comprise at least one of the following:

[0202] g) seventh indication information for indicating whether the second data packet carries the IP identification field; for example, in the second data packet, when the value of the seventh indication information is set to 0, it is used to indicate that the second data packet does not carry the IP identification field; and when the value of the seventh indication information is set to 1, it is used to indicate that the second data packet carries the IP identification field;

[0203] h) eighth indication information for indicating whether the second data packet carries the UDP check field; for example, in the second data packet, when the value of the eighth indication information is set to 0, it is used to indicate that the second data packet does not carry the UDP check field; and when the value of the eighth indication information is set to 1, it is used to indicate that the second data packet carries the UDP check field; for example, for satellite voice service, in the case of always disabling the UDP check function, the second data packet does not comprise the eighth indication information;

[0204] i) ninth indication information for indicating the value of the RTP mark field;

[0205] j) a tenth indication information, used for indicating whether the second data packet carries a static field; the static field comprises at least one of the following: an RTP static field, a UDP static field, an IP static field; for example, in the second data packet, when the value of the tenth indication information is set as 1, it is used for indicating that the second data packet carries a static field; and when the value of the tenth indication information is set as 0, it is used for indicating that the second data packet does not carry a static field;

[0206] k) an eleventh indication information, used for indicating whether the second data packet carries an RTP timestamp field; for example, in the second data packet, when the value of the eleventh indication information is set as 1, it is used for indicating that the second data packet carries an RTP timestamp field; and when the value of the eleventh indication information is set as 0, it is used for indicating that the second data packet does not carry an RTP timestamp field;

[0207] m) a twelfth indication information, used for indicating whether the second data packet carries an RTP sequence number field; for example, in the second data packet, when the value of the twelfth indication information is set as 1, it is used for indicating that the second data packet carries an RTP sequence number field; and when the value of the twelfth indication information is set as 0, it is used for indicating that the second data packet does not carry an RTP sequence number field.

[0208] Optionally, the data transmission method in the embodiments of the present application can further comprise at least one of the following:

[0209] - in the case that the second data packet is a PDCP data packet (such as carrying voice service data), the second node acquires the RTP sequence number corresponding to the second data packet according to the PDCP sequence number of the second data packet; for example, the PDCP sequence is PDCP COUNT, and the low 16 bits of the PDCP COUNT (such as a 32-bit variable) value corresponding to the second data packet is equal to the RTP sequence number corresponding to the first data packet.

[0210] - in the case that the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp field, the second node stores the RTP timestamp information in the RTP timestamp field.

[0211] - in a case that the second data packet is a PDCP data packet (e.g. carrying voice service data) and the second data packet does not carry an RTP timestamp field, the second node obtains the RTP timestamp information corresponding to the second data packet according to the PDCP sequence number of the second data packet and the stored RTP timestamp information. For example, in a case that the second data packet does not carry the RTP timestamp information, the second node can obtain the RTP timestamp information corresponding to the second data packet based on the PDCP sequence number of the second data packet and predetermined time increment information. It should be noted that in a voice service scenario, voice service data is periodically generated, and therefore the time difference of the RTP timestamps corresponding to the continuously generated voice service packets is a fixed value. For example, assuming that the time difference of the RTP timestamps corresponding to the continuously generated voice service packets is 20s, the timestamp of the #1 RTP data packet is 12:00:00, the timestamp of the #2 RTP data packet is 12:00:20, the timestamp of the #3 RTP data packet is 12:00:40, and so on. Assuming that the RTP sequence number corresponding to the data packet received by the second node is #5, and the stored timestamp information (12:00:40) is associated with the RTP sequence number #3, the second node can deduce that the timestamp corresponding to the data packet with the RTP sequence number #5 is 12:01:20.

[0212] - in a case that the second data packet is a PDCP data packet and the second data packet does not carry an IP identifier field, the second node obtains the IP identifier information corresponding to the second data packet according to the PDCP sequence number of the second data packet. For example, the IP identifier field is assigned starting from 0 with a step of 1, and therefore the IP identifier corresponding to the #1 data packet is 0, the IP identifier corresponding to the #2 data packet is 1, and so on. The IP identifier corresponding to the first data packet can be obtained based on the above rule.

[0213] The present application will be described in detail below with reference to specific embodiments.

[0214] Embodiment One

[0215] In the present embodiment one, the static domain information based on the control plane transmission header is mainly described. As shown in FIG. 4, the specific data transmission process includes the following steps.

[0216] Step 1: the first node sends the first data packet to the second node through control plane signaling (e.g. RRC message), and the first data packet includes the static domain information of the header.

[0217] Optionally, the first node is a terminal, and the second node is a network node; or, the first node is a network node, and the second node is a terminal.

[0218] Optionally, the static domain information of the header can be as described in the above embodiments, which will not be described herein again.

[0219] Optionally, the first data packet further comprises dynamic domain negotiation information of the header, which can be as described in the above embodiments and will not be repeated here.

[0220] Step 2: After receiving the first data packet sent by the first node, the second node stores the static domain information of the packet and the related dynamic domain negotiation information based on the first data packet.

[0221] Step 3: The second node sends feedback information to the first node through an RRC message, and the feedback information is used to feed back that the second node successfully stores the static domain information of the packet and the related dynamic domain negotiation information.

[0222] Step 4: The first node sends a second data packet to the second node, and the second data packet does not comprise the static domain information of the header, and the second data packet is specifically a user plane data packet, such as a PDCP data packet carrying a load.

[0223] Optionally, the second data packet can comprise irregular dynamic domains of the packet, and can comprise at least one of the seventh indication information to the twelfth indication information as described above, which will not be repeated here.

[0224] Optionally, the second data packet can comprise dynamic domain information of the header, that is, the second data packet only transmits the dynamic domain information of the header, and does not transmit the static domain information of the header. At this time, only the static domain of the header corresponding to the second data packet needs to be recovered according to the stored static domain information of the header, and the dynamic domain information of the header can be directly obtained from the corresponding second data packet.

[0225] Step 5: After receiving the second data packet sent by the first node, the second node recovers the static domain of the header corresponding to the second data packet based on the stored static domain information of the header, and performs a first operation, which comprises at least one of the following:

[0226] - In the case that the second data packet is a PDCP data packet, the RTP sequence number corresponding to the second data packet is obtained according to the PDCP sequence number of the second data packet;

[0227] - In the case that the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp domain, the RTP timestamp information in the RTP timestamp domain is stored;

[0228] - in a case that the second data packet is a PDCP data packet and the second data packet does not carry an RTP timestamp field, obtaining the RTP timestamp information corresponding to the second data packet according to the PDCP sequence number of the second data packet and the stored RTP timestamp information;

[0229] - in a case that the second data packet is a PDCP data packet and the second data packet does not carry an IP identification field, obtaining the IP identification information corresponding to the second data packet according to the PDCP sequence number of the second data packet.

[0230] Embodiment Two

[0231] In the embodiment two, the static field information based on the user plane signaling transmission header is mainly explained. As shown in FIG. 5, the specific data transmission process includes:

[0232] Step 1: the first node sends a first data packet to the second node through a user plane signaling (such as a PDCP control packet), and the first data packet includes static field information of a header.

[0233] Optionally, the first node is a terminal, and the second node is a network node; or, the first node is a network node, and the second node is a terminal.

[0234] Optionally, the static field information of the header can be as described in the above embodiments, which will not be repeated here.

[0235] Optionally, the first data packet further includes dynamic field negotiation information of the header, which can be as described in the above embodiments, which will not be repeated here.

[0236] Optionally, the first data packet further includes at least one of the first to sixth indication information, specifically, the first indication information is used to indicate whether the second data packet carries an IP identification field, the second indication information is used to indicate whether the second data packet carries a UDP check field, the third indication information is used to indicate the value of an RTP mark field, the fourth indication information is used to indicate whether the second data packet carries a static field, the fifth indication information is used to indicate whether the second data packet carries an RTP timestamp field, and the sixth indication information is used to indicate whether the second data packet carries an RTP sequence number field.

[0237] Step 2: after receiving the first data packet sent by the first node, the second node stores the static field information of the message based on the first data packet.

[0238] Step 3: the second node sends feedback information to the first node through a PDCP control packet, and the feedback information is used to feed back that the second node successfully stores the static field information of the message.

[0239] Step 4: The first node sends a second data packet to the second node, wherein the second data packet does not include the static domain information of the header, and the second data packet is specifically a user plane data packet, such as a PDCP data packet carrying a load.

[0240] Optionally, the second data packet can include irregular dynamic domains of the message, and can include at least one of the seventh indication information to the twelfth indication information as described above, which can be implemented as described above in the embodiments and will not be described here again.

[0241] Step 5: After receiving the second data packet sent by the first node, the second node restores the static domain of the header corresponding to the second data packet based on the stored static domain information of the header, and performs a first operation, wherein the first operation includes at least one of the following:

[0242] - In the case where the second data packet is a PDCP data packet, the RTP sequence number corresponding to the second data packet is obtained according to the PDCP sequence number of the second data packet.

[0243] - In the case where the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp domain, the RTP timestamp information in the RTP timestamp domain is stored.

[0244] - In the case where the second data packet is a PDCP data packet and the second data packet does not carry an RTP timestamp domain, the RTP timestamp information corresponding to the second data packet is obtained according to the PDCP sequence number of the second data packet and the stored RTP timestamp information.

[0245] - In the case where the second data packet is a PDCP data packet and the second data packet does not carry an IP identifier domain, the IP identifier information corresponding to the second data packet is obtained according to the PDCP sequence number of the second data packet.

[0246] Embodiment Three

[0247] In this embodiment three, the static domain information of the header of the user plane data packet is mainly described. As shown in FIG. 6A, the specific data transmission process includes:

[0248] Step 1: The first node sends a first data packet to the second node through a user plane data packet (such as a PDCP data packet), wherein the first data packet includes the static domain information of the header.

[0249] Optionally, the first node is a terminal, and the second node is a network node; or the first node is a network node, and the second node is a terminal.

[0250] Optionally, the static field information of the header can be as described in the above embodiments, which will not be repeated here.

[0251] Optionally, the first data packet further comprises dynamic field negotiation information of the header and a payload (such as voice service data), and the dynamic field negotiation information of the header can be as described in the above embodiments, which will not be repeated here.

[0252] Optionally, the first data packet further comprises at least one of the first to sixth indication information as described above, which can be as described in the above embodiments, which will not be repeated here.

[0253] Step 2: After receiving the first data packet sent by the first node, the second node stores the static field information of the message based on the first data packet.

[0254] Optionally, after receiving the first data packet sent by the first node, the second node can decompress the dynamic field of the header corresponding to the first data packet according to a preset rule, which can be as described in the above embodiments.

[0255] Step 3: The second node sends feedback information to the first node through a PDCP control packet, and the feedback information is used to feedback that the second node successfully stores the static field information of the message.

[0256] Step 4: The first node sends a second data packet to the second node, and the second data packet does not comprise the static field information of the header, and the second data packet is specifically a user plane data packet, such as a PDCP data packet carrying a payload.

[0257] Optionally, the second data packet can comprise irregular dynamic fields of the message, and can comprise at least one of the seventh to twelfth indication information as described above, which can be as described in the above embodiments, which will not be repeated here.

[0258] Step 5: After receiving the second data packet sent by the first node, the second node restores the static field of the header corresponding to the second data packet based on the stored static field information of the header, and performs a first operation, which comprises at least one of the following:

[0259] In the case that the second data packet is a PDCP data packet, the RTP sequence number corresponding to the second data packet is obtained according to the PDCP sequence number of the second data packet;

[0260] In the case that the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp field, the RTP timestamp information in the RTP timestamp field is stored;

[0261] - in a case that the second data packet is a PDCP data packet and the second data packet does not carry an RTP timestamp field, obtaining the RTP timestamp information corresponding to the second data packet according to the PDCP sequence number of the second data packet and the stored RTP timestamp information;

[0262] - in a case that the second data packet is a PDCP data packet and the second data packet does not carry an IP identification field, obtaining the IP identification information corresponding to the second data packet according to the PDCP sequence number of the second data packet.

[0263] Embodiment Four

[0264] In this embodiment four, the static field information based on the control plane transmission header is mainly explained. As shown in FIG. 6B, the specific data transmission process includes:

[0265] Step 1: the first node sends a first data packet to the second node through control plane signaling (such as RRC message), and the first data packet includes the static field information of the header.

[0266] Optionally, the first node is a terminal, and the second node is a network node; or, the first node is a network node, and the second node is a terminal.

[0267] Optionally, the static field information of the header can be as described in the above embodiments, which will not be repeated here.

[0268] Step 2: after receiving the first data packet sent by the first node, the second node stores the static field information of the message based on the first data packet.

[0269] Step 3: optionally, the second node sends feedback information to the first node through RRC message, and the feedback information is used to feed back that the second node successfully stores the static field information of the message.

[0270] Step 4: the first node sends a second data packet to the second node, and the second data packet does not include the static field information of the header, and the second data packet is specifically a user plane data packet, such as a PDCP data packet carrying a load.

[0271] Optionally, the second data packet can include all dynamic fields of the message. That is, the second data packet only transmits the dynamic field information of the header, but does not transmit the static field information of the header. That is, the second data packet corresponds to all dynamic field information of the header, which is transmitted as usual. It can be understood that the dynamic field of the header is not processed.

[0272] Step 5: After receiving the second data packet sent by the first node, the second node restores the static field of the header corresponding to the second data packet based on the stored static field information of the header. That is, at this time, only the static field of the header corresponding to the second data packet needs to be restored according to the stored static field information of the header, and the dynamic field information of the header can be directly obtained from the corresponding second data packet.

[0273] The data transmission method provided by the embodiment of the present application can be executed by the data transmission device. The data transmission device is taken as an example to illustrate the data transmission device provided by the embodiment of the present application.

[0274] The data transmission device provided by the embodiment of the present application can be a communication device or a component in the communication device, for example, a chip. The communication device can be a terminal, a network side device or a server, etc. The terminal can include, but is not limited to, the types of the terminal 11 listed above, the network side device can include, but is not limited to, the types of the network side device 12 listed above, and the embodiment of the present application does not make specific limitations.

[0275] The data transmission device includes a receiving module, a sending module and a processing module. The receiving module, the sending module and the processing module can be implemented by software or hardware. When implemented by hardware, the processing module can be implemented by a processor, which can include a general processor, a special purpose processor, etc., for example, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), an artificial intelligent (AI) processor, a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a network processor (NP), a field programmable gate array (FPGA) or other programmable logic devices, a gate circuit, a transistor, a discrete hardware component, etc. The receiving module and the sending module can be implemented by a communication interface, which can include one or more of a transceiver, a pin, a circuit, a bus, a radio frequency unit, etc.

[0276] Specifically, referring to FIG. 7, when the data transmission device is the first node or a component in the first node, the data transmission device 70 includes:

[0277] The first sending module 71 is configured to send a first data packet to a second node, wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of the following:

[0278] static field information of a real-time transport protocol (RTP) header;

[0279] static field information of a user datagram protocol (UDP) header;

[0280] static field information of an internet protocol (IP) header.

[0281] Optionally, the first data packet does not comprise dynamic field information of the header.

[0282] Optionally, the dynamic field information of the header comprises at least one of the following: dynamic field information of the RTP header, dynamic field information of the UDP header, and dynamic field information of the IP header.

[0283] Optionally, the first data packet further comprises dynamic field negotiation information of the header, and the dynamic field negotiation information of the header comprises at least one of the following:

[0284] negotiation information of an RTP dynamic field;

[0285] negotiation information of a UDP dynamic field;

[0286] negotiation information of an IP dynamic field.

[0287] Optionally, the negotiation information of the RTP dynamic field comprises at least one of the following: negotiation information of an RTP sequence number field and negotiation information of an RTP timestamp field.

[0288] And / or, the negotiation information of the UDP dynamic field comprises negotiation information of a UDP check field.

[0289] And / or, the negotiation information of the IP dynamic field comprises negotiation information of an IP identification field.

[0290] Optionally, the negotiation information of the RTP sequence number field comprises at least one of the following: mapping relationship information of an RTP sequence number and a PDCP sequence number, and function information for enabling derivation of the RTP sequence number based on the PDCP sequence number.

[0291] And / or, the negotiation information of the UDP check field comprises any one of the following: information for enabling a UDP layer check function, and information for disabling the UDP layer check function.

[0292] And / or, the negotiation information of the IP identification domain includes at least one of the following: allocation rule information of the IP identification domain, allocation step information of the IP identification domain, function information enabling derivation of the IP identification domain based on the PDCP sequence number, mapping relationship information of the IP identification domain and the PDCP sequence number.

[0293] Optionally, the first data packet further includes at least one of the following:

[0294] First indication information, the first indication information is used to indicate whether the first data packet and / or the second data packet carries the IP identification domain;

[0295] Second indication information, the second indication information is used to indicate whether the first data packet and / or the second data packet carries the UDP check field;

[0296] Third indication information, the third indication information is used to indicate the value of the RTP mark field;

[0297] Fourth indication information, the fourth indication information is used to indicate whether the first data packet and / or the second data packet carries the static field;

[0298] Fifth indication information, the fifth indication information is used to indicate whether the first data packet and / or the second data packet carries the RTP timestamp field;

[0299] Sixth indication information, the sixth indication information is used to indicate whether the first data packet and / or the second data packet carries the RTP sequence number field.

[0300] Optionally, the first sending module 71 is specifically configured to: send the first data packet to the second node through control plane signaling or user plane signaling.

[0301] Optionally, the control plane signaling is a radio resource control (RRC) message.

[0302] And / or, the user plane signaling is a user plane control packet.

[0303] Optionally, the data transmission apparatus 70 further includes:

[0304] A first receiving module is configured to receive feedback information sent by the second node, and the feedback information is used to feed back that the second node successfully stores the static field information of the header.

[0305] Optionally, the data transmission apparatus 70 further includes:

[0306] A second sending module is configured to send a second data packet to the second node, and the second data packet does not include the static field information of the header.

[0307] Optionally, the second data packet comprises dynamic domain information of a header.

[0308] Optionally, the second data packet does not comprise at least one of an RTP sequence number domain and an RTP timestamp domain.

[0309] Optionally, the second data packet comprises at least one of:

[0310] Seventh indication information, used for indicating whether the second data packet carries an IP identification domain;

[0311] Eighth indication information, used for indicating whether the second data packet carries a UDP check domain;

[0312] Ninth indication information, used for indicating a value of an RTP mark domain;

[0313] Tenth indication information, used for indicating whether the second data packet carries a static domain;

[0314] Eleventh indication information, used for indicating whether the second data packet carries an RTP timestamp domain;

[0315] Twelfth indication information, used for indicating whether the second data packet carries an RTP sequence number domain.

[0316] The data transmission apparatus provided in the embodiments of the present application can implement each process of the method embodiment shown in FIG. 2 and achieve the same technical effects. To avoid repetition, details are not described herein.

[0317] Referring to FIG. 8, when the data transmission apparatus is a second node or a component in the second node, the data transmission apparatus 80 comprises:

[0318] A second receiving module 81, configured to receive a first data packet sent by a first node; wherein the first data packet comprises static domain information of a header, and the static domain information of the header comprises at least one of:

[0319] Static domain information of an RTP header;

[0320] Static domain information of a UDP header;

[0321] Static domain information of an IP header.

[0322] Optionally, the first data packet does not comprise dynamic domain information of a header.

[0323] Optionally, the dynamic domain information of the header comprises at least one of: dynamic domain information of an RTP header, dynamic domain information of a UDP header, and dynamic domain information of an IP header.

[0324] Optionally, the first data packet further comprises dynamic field negotiation information of the header, and the dynamic field negotiation information of the header comprises at least one of the following:

[0325] RTP dynamic field negotiation information;

[0326] UDP dynamic field negotiation information;

[0327] IP dynamic field negotiation information.

[0328] Optionally, the RTP dynamic field negotiation information comprises at least one of the following: RTP sequence number field negotiation information, RTP timestamp field negotiation information;

[0329] And / or, the UDP dynamic field negotiation information comprises UDP check field negotiation information;

[0330] And / or, the IP dynamic field negotiation information comprises IP identification field negotiation information.

[0331] Optionally, the RTP sequence number field negotiation information comprises at least one of the following: mapping relationship information of RTP sequence number and PDCP sequence number, function information enabling derivation of RTP sequence number based on PDCP sequence number;

[0332] And / or, the UDP check field negotiation information comprises any one of the following: information enabling UDP layer check function, information disabling UDP layer check function;

[0333] And / or, the IP identification field negotiation information comprises at least one of the following: allocation rule information of the IP identification field, allocation step information of the IP identification field, function information enabling derivation of the IP identification field based on PDCP sequence number, mapping relationship information of the IP identification field and PDCP sequence number.

[0334] Optionally, the first data packet further comprises at least one of the following:

[0335] First indication information, the first indication information being used for indicating whether the first data packet and / or second data packet carries an IP identification field;

[0336] Second indication information, the second indication information being used for indicating whether the first data packet and / or second data packet carries a UDP check field;

[0337] Third indication information, the third indication information being used for indicating a value of an RTP marker field;

[0338] Fourth indication information, the fourth indication information being used for indicating whether the first data packet and / or second data packet carries a static field;

[0339] Fifth indication information, used for indicating whether the first data packet and / or the second data packet carries an RTP timestamp field;

[0340] Sixth indication information, used for indicating whether the first data packet and / or the second data packet carries an RTP sequence number field.

[0341] Optionally, the second receiving module 81 is specifically configured to receive the first data packet sent by the first node through control plane signaling or user plane signaling.

[0342] Optionally, the control plane signaling is an RRC message.

[0343] And / or, the user plane signaling is a user plane control packet.

[0344] Optionally, the data transmission apparatus 80 further includes:

[0345] A first processing module, configured to perform at least one of the following:

[0346] In a case where the first data packet is a packet data convergence protocol (PDCP) data packet, the first processing module is configured to acquire an RTP sequence number corresponding to the first data packet according to a PDCP sequence number of the first data packet.

[0347] In a case where the first data packet is a PDCP data packet and the first data packet carries an RTP timestamp field, the first processing module is configured to store RTP timestamp information in the RTP timestamp field.

[0348] In a case where the first data packet is a PDCP data packet and the first data packet does not carry an RTP timestamp field, the first processing module is configured to acquire RTP timestamp information corresponding to the first data packet according to a PDCP sequence number of the first data packet and the stored RTP timestamp information.

[0349] In a case where the first data packet is a PDCP data packet and the first data packet does not carry an IP identifier field, the first processing module is configured to acquire IP identifier information corresponding to the first data packet according to a PDCP sequence number of the first data packet.

[0350] Optionally, the data transmission apparatus 80 further includes:

[0351] A storage module, configured to store static field information of the header.

[0352] Optionally, the data transmission apparatus 80 further includes:

[0353] A third sending module, configured to send feedback information to the first node, the feedback information being used for feeding back that the second node successfully stores the static field information of the header.

[0354] Optionally, the data transmission device 80 further comprises:

[0355] a third receiving module, configured to receive a second data packet sent by the first node, wherein the second data packet does not comprise the static field information of the header;

[0356] a restoring module, configured to restore the static field of the header corresponding to the second data packet according to the stored static field information of the header.

[0357] Optionally, the second data packet comprises at least one of the following:

[0358] seventh indication information, used to indicate whether the second data packet carries an IP identification field;

[0359] eighth indication information, used to indicate whether the second data packet carries a UDP check field;

[0360] ninth indication information, used to indicate the value of an RTP mark field;

[0361] tenth indication information, used to indicate whether the second data packet carries a static field;

[0362] eleventh indication information, used to indicate whether the second data packet carries an RTP timestamp field;

[0363] twelfth indication information, used to indicate whether the second data packet carries an RTP sequence number field.

[0364] Optionally, the data transmission device 80 further comprises:

[0365] a second processing module, configured to perform at least one of the following:

[0366] in a case where the second data packet is a PDCP data packet, acquiring the RTP sequence number corresponding to the second data packet according to the PDCP sequence number of the second data packet;

[0367] in a case where the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp field, storing the RTP timestamp information in the RTP timestamp field;

[0368] in a case where the second data packet is a PDCP data packet and the second data packet does not carry an RTP timestamp field, acquiring the RTP timestamp information corresponding to the second data packet according to the PDCP sequence number of the second data packet and the stored RTP timestamp information;

[0369] When the second data packet is a PDCP data packet and the second data packet does not carry an IP identification domain, the IP identification information corresponding to the second data packet is obtained according to a PDCP sequence number of the second data packet.

[0370] The data transmission apparatus provided by the embodiments of the present application can implement each process of the method embodiment shown in FIG. 3 and achieve the same technical effects. To avoid repetition, details are not described herein.

[0371] As shown in FIG. 9, the embodiments of the present application further provide a communication device 90, which includes a processor 91 and a memory 92, and the memory 92 stores programs or instructions executable on the processor 91. When the programs or instructions are executed by the processor 91, each step of the above data transmission method embodiment is implemented, and the same technical effects can be achieved. To avoid repetition, details are not described herein.

[0372] The embodiments of the present application further provide a terminal, which includes a processor and a communication interface. The communication interface is coupled to the processor, and the processor is configured to run programs or instructions to implement the steps in the method embodiments shown in FIG. 2 or FIG. 3. Each implementation process and implementation manner of the above method embodiments can be applied to the terminal embodiment, and the same technical effects can be achieved. The terminal can be the data transmission apparatus shown in FIG. 7 or FIG. 8.

[0373] Specifically, FIG. 10 is a schematic diagram of a hardware structure of a terminal for implementing the embodiments of the present application.

[0374] The terminal 1000 includes, but is not limited to, at least part of components such as a radio frequency unit 1001, a network module 1002, an audio output unit 1003, an input unit 1004, a sensor 1005, a display unit 1006, a user input unit 1007, an interface unit 1008, a memory 1009, and a processor 1010.

[0375] Those skilled in the art can understand that the terminal 1000 can further include a power supply (such as a battery) for supplying power to each component. The power supply can be logically connected to the processor 1010 through a power management system, so as to realize functions such as power management, discharge management, and power consumption management through the power management system. The terminal structure shown in FIG. 10 does not constitute a limitation on the terminal, and the terminal can include more or fewer components than those shown, or combine certain components, or have different component arrangements, which are not described herein.

[0376] It should be understood that in the embodiments of the present application, the input unit 1004 can include a graphics processor 10041 and a microphone 10042, and the graphics processor 10041 processes image data of a still picture or a video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The display unit 1006 can include a display panel 10061, which can be configured in the form of a liquid crystal display, an organic light-emitting diode, etc. The user input unit 1007 includes at least one of a touch panel 10071 and other input devices 10072. The touch panel 10071 is also called a touch screen. The touch panel 10071 can include two parts of a touch detection device and a touch controller. The other input devices 10072 can include, but are not limited to, a physical keyboard, function keys (such as volume control keys, on-off keys, etc.), a trackball, a mouse, a joystick, and the like, which will not be described here.

[0377] In the embodiments of the present application, after the radio frequency unit 1001 receives the downlink data from the network side device, it can be transmitted to the processor 1010 for processing. In addition, the radio frequency unit 1001 can send uplink data to the network side device. Generally, the radio frequency unit 1001 includes, but is not limited to, an antenna, an amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, etc.

[0378] The memory 1009 can be used to store software programs or instructions and various data. The memory 1009 can mainly include a first storage area storing programs or instructions and a second storage area storing data, wherein the first storage area can store an operating system, application programs or instructions required by at least one function (such as a sound playing function, an image playing function, etc.), and the like. In addition, the memory 1009 can include a volatile memory or a non-volatile memory. The non-volatile memory can be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), or a flash memory. The volatile memory can be a Random Access Memory (RAM), a Static RAM (SRAM), a Dynamic RAM (DRAM), a Synchronous DRAM (SDRAM), a Double Data Rate SDRAM (DDR SDRAM), an Enhanced SDRAM (ESDRAM), a Synch link DRAM (SLDRAM), and a Direct Rambus RAM (DRRAM). The memory 1009 in the embodiments of the present application includes but is not limited to these and any other suitable types of memory.

[0379] The processor 1010 can include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor, wherein the application processor mainly processes operations related to an operating system, a user interface, and an application program, and the modem processor mainly processes wireless communication signals, such as a baseband processor. It can be understood that the above-mentioned modem processor can also not be integrated into the processor 1010.

[0380] The radio frequency unit 1001 is configured to send a first data packet to a network side device or receive a first data packet sent by the network side device; the first data packet includes static domain information of a header, and the static domain information of the header includes at least one of the following: static domain information of a Real-time Transport Protocol (RTP) header; static domain information of a User Datagram Protocol (UDP) header; and static domain information of an Internet Protocol (IP) header.

[0381] It can be understood that the implementation process of each implementation mode mentioned in the embodiment can refer to the related description of the above-mentioned data transmission method embodiment, and achieve the same or corresponding technical effects. To avoid repetition, it will not be repeated here.

[0382] The embodiment of the application further provides a network side device, comprising a processor and a communication interface, the communication interface and the processor are coupled, the processor is used to run programs or instructions, and the steps of the method embodiments shown in FIG. 2 or FIG. 3 are realized. Each implementation process and implementation mode of the above-mentioned method embodiments can be applied to the network side device embodiment, and the same technical effects can be achieved.

[0383] Specifically, the embodiment of the application further provides a network side device, which can be the data transmission apparatus shown in FIG. 7 or FIG. 8. As shown in FIG. 11, the network side device 110 comprises an antenna 111, a radio frequency device 112, a baseband device 113, a processor 114 and a memory 115. The antenna 111 is connected with the radio frequency device 112. In the uplink direction, the radio frequency device 112 receives information through the antenna 111, and sends the received information to the baseband device 113 for processing. In the downlink direction, the baseband device 113 processes the information to be sent and sends it to the radio frequency device 112, and the radio frequency device 112 processes the received information and sends it out through the antenna 111.

[0384] The method performed by the network side device in the above embodiment can be implemented in the baseband device 113, which comprises a baseband processor.

[0385] The baseband device 113 may, for example, comprise at least one baseband board, and a plurality of chips are arranged on the baseband board, as shown in FIG. 11. One of the chips is, for example, a baseband processor, which is connected with the memory 115 through a bus interface to call the programs in the memory 115 and execute the network device operations shown in the above method embodiments.

[0386] The network side device can further comprise a network interface 116, which is, for example, a common public radio interface (Common Public Radio Interface, CPRI).

[0387] Specifically, the network side device 110 of the embodiment of the application further comprises instructions or programs stored in the memory 115 and executable on the processor 114, and the processor 114 calls the instructions or programs in the memory 115 to execute the method performed by each module shown in FIG. 7 or FIG. 8, and achieve the same technical effects. To avoid repetition, it will not be repeated here.

[0388] The embodiment of the present application further provides a readable storage medium, which stores a program or instructions, and the program or instructions are executed by a processor to realize the processes of the data transmission method embodiments and achieve the same technical effects. To avoid repetition, details are not described herein.

[0389] The processor is the processor in the terminal in the above embodiments. The readable storage medium includes a computer readable storage medium, such as a computer readable only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc. In some examples, the readable storage medium can be a non-transitory readable storage medium.

[0390] The embodiment of the present application further provides a chip, which includes a processor and a communication interface, the communication interface is coupled with the processor, and the processor is used to run a program or instructions to realize the processes of the data transmission method embodiments and achieve the same technical effects. To avoid repetition, details are not described herein.

[0391] It should be understood that the chip mentioned in the embodiment of the present application can also be referred to as a system chip, a system chip, a chip system or a system on chip, etc.

[0392] The embodiment of the present application further provides a computer program / program product, which is stored in a storage medium and is executed by at least one processor to realize the processes of the data transmission method embodiments and achieve the same technical effects. To avoid repetition, details are not described herein.

[0393] The embodiment of the present application further provides a communication system, which includes a terminal and a network side device. The terminal can be used to execute the steps of the data transmission method shown in FIG. 2, and the network side device can be used to execute the steps of the data transmission method shown in FIG. 3. Alternatively, the terminal can be used to execute the steps of the data transmission method shown in FIG. 3, and the network side device can be used to execute the steps of the data transmission method shown in FIG. 2.

[0394] It should be noted that, in the present document, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element. Furthermore, it is to be understood that the method and apparatus of the present application can be carried out by specific hardware, software, or a combination thereof, and that the method and apparatus of the present application can be implemented in a computer program product that is executed by a computer. The computer program product can comprise a computer-readable storage medium having stored thereon instructions that, when executed by a computer, implement the method of the present application.

[0395] From the above description of the embodiments, it is clear that the above-mentioned method can be realized by means of a computer software product and a general hardware platform, of course, it can also be realized by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disc, optical disc, etc.), and includes a plurality of instructions for making the terminal or network side device execute the method described in each embodiment of the present application.

[0396] The embodiments of the present application are described above in combination with the drawings, but the present application is not limited to the above-mentioned specific embodiments, the above-mentioned specific embodiments are only illustrative, but not restrictive, and those skilled in the art can make many forms of embodiments under the inspiration of the present application without departing from the scope of the present application and the scope protected by the claims.

Claims

A data transmission method, comprising: a first node sending a first data packet to a second node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of: static field information of a real-time transport protocol (RTP) header; static field information of a user datagram protocol (UDP) header; static field information of an internet protocol (IP) header. The method of claim 1, wherein, The first data packet does not comprise dynamic field information of the header. The method of claim 2, wherein, The dynamic field information of the header comprises at least one of: dynamic field information of the RTP header, dynamic field information of the UDP header, and dynamic field information of the IP header. The method of claim 1, wherein, The first data packet further comprises dynamic field negotiation information of the header, and the dynamic field negotiation information of the header comprises at least one of: negotiation information of an RTP dynamic field; negotiation information of a UDP dynamic field; negotiation information of an IP dynamic field. According to claim 4, wherein the negotiation information of the RTP dynamic field comprises at least one of: negotiation information of an RTP sequence number field and negotiation information of an RTP timestamp field; and / or the negotiation information of the UDP dynamic field comprises negotiation information of a UDP check field; and / or the negotiation information of the IP dynamic field comprises negotiation information of an IP identification field. According to claim 5, wherein the negotiation information of the RTP sequence number field comprises at least one of: mapping relationship information of an RTP sequence number and a PDCP sequence number, and function information enabling derivation of the RTP sequence number based on the PDCP sequence number; and / or the negotiation information of the UDP check field comprises any one of: information enabling a UDP layer check function and information disabling the UDP layer check function; and / or the negotiation information of the IP identification field comprises at least one of: allocation rule information of the IP identification field, allocation step information of the IP identification field, function information enabling derivation of the IP identification field based on the PDCP sequence number, and mapping relationship information of the IP identification field and the PDCP sequence number. The method of claim 1, wherein, The first data packet further comprises at least one of: first indication information for indicating whether the first data packet and / or a second data packet carries an IP identification field; second indication information for indicating whether the first data packet and / or the second data packet carries a UDP check field; third indication information for indicating a value of an RTP marker field; fourth indication information for indicating whether the first data packet and / or the second data packet carries a static field; fifth indication information for indicating whether the first data packet and / or the second data packet carries an RTP timestamp field; sixth indication information for indicating whether the first data packet and / or the second data packet carries an RTP sequence number field. The method according to any one of claims 1 to 7, wherein The first node sending the first data packet to the second node comprises: the first node sending the first data packet to the second node through control plane signaling or user plane signaling. According to claim 8, wherein the control plane signaling is a radio resource control (RRC) message; and / or, The user plane signaling is a user plane control packet. The method according to any one of claims 1 to 9, wherein The method further includes: The first node receives feedback information sent by the second node, and the feedback information is used to feed back that the second node successfully stores the static domain information of the header. The method according to any one of claims 1 to 10, wherein The method further includes: The first node sends a second data packet to the second node, and the second data packet does not include the static domain information of the header. The method of claim 11, wherein, The second data packet includes dynamic domain information of the header. The method according to claim 11 or 12, wherein The second data packet does not include at least one of an RTP sequence number field and an RTP timestamp field. The method of claim 11, wherein, The second data packet includes at least one of: Seventh indication information used to indicate whether the second data packet carries an IP identification field; Eighth indication information used to indicate whether the second data packet carries a UDP check field; Ninth indication information used to indicate a value of an RTP mark field; Tenth indication information used to indicate whether the second data packet carries a static field; Eleventh indication information used to indicate whether the second data packet carries an RTP timestamp field; Twelfth indication information used to indicate whether the second data packet carries an RTP sequence number field. A data transmission method, comprising: The second node receives a first data packet sent by the first node; The first data packet includes static domain information of a header, and the static domain information of the header includes at least one of: Static domain information of an RTP header; Static domain information of a UDP header; Static domain information of an IP header. The method of claim 15, wherein, The first data packet does not include dynamic domain information of the header. The method of claim 15, wherein, The first data packet further includes dynamic domain negotiation information of the header, and the dynamic domain negotiation information of the header includes at least one of: Negotiation information of an RTP dynamic domain; Negotiation information of a UDP dynamic domain; Negotiation information of an IP dynamic domain. The method of claim 15, wherein, The first data packet further includes at least one of: First indication information used to indicate whether the first data packet and / or a second data packet carries an IP identification field; Second indication information used to indicate whether the first data packet and / or the second data packet carries a UDP check field; Third indication information used to indicate a value of an RTP mark field; Fourth indication information used to indicate whether the first data packet and / or the second data packet carries a static field; Fifth indication information used to indicate whether the first data packet and / or the second data packet carries an RTP timestamp field; Sixth indication information used to indicate whether the first data packet and / or the second data packet carries an RTP sequence number field. The method according to any one of claims 15 to 18, wherein The second node receives a first data packet sent by the first node, comprising: The second node receives the first data packet sent by the first node through control plane signaling or user plane signaling. The method of claim 15, wherein, The method further includes at least one of: In a case where the first data packet is a PDCP data packet, and the first data packet carries an RTP timestamp field, the second node stores RTP timestamp information in the RTP timestamp field; In a case where the first data packet is a PDCP data packet, and the first data packet does not carry an RTP timestamp field, the second node acquires RTP timestamp information corresponding to the first data packet according to the PDCP sequence number of the first data packet and the stored RTP timestamp information; In a case where the first data packet is a PDCP data packet, and the first data packet does not carry an IP identification field, the second node acquires IP identification information corresponding to the first data packet according to the PDCP sequence number of the first data packet. The method further comprises: The method according to any one of claims 15 to 20, wherein The second node stores the static field information of the header. The method further comprises: The method of claim 21, wherein, The second node sends feedback information to the first node, the feedback information being used for feeding back that the second node successfully stores the static field information of the header. The method further comprises: The method according to any one of claims 15 to 22, wherein The second node receives a second data packet sent by the first node, the second data packet not including static field information of a header; The second node recovers the static field of the header corresponding to the second data packet according to the stored static field information of the header. The second data packet comprises at least one of the following: The method of claim 23, wherein, Seventh indication information, the seventh indication information being used for indicating whether the second data packet carries an IP identification field; Eighth indication information, the eighth indication information being used for indicating whether the second data packet carries a UDP check field; Ninth indication information, the ninth indication information being used for indicating a value of an RTP mark field; Tenth indication information, the tenth indication information being used for indicating whether the second data packet carries a static field; Eleventh indication information, the eleventh indication information being used for indicating whether the second data packet carries an RTP timestamp field; Twelfth indication information, the twelfth indication information being used for indicating whether the second data packet carries an RTP sequence number field. The method further comprises at least one of the following: The method according to claim 23 or 24, wherein In a case where the second data packet is a PDCP data packet, the second node acquires an RTP sequence number corresponding to the second data packet according to a PDCP sequence number of the second data packet; In a case where the second data packet is a PDCP data packet, and the second data packet carries an RTP timestamp field, the second node stores RTP timestamp information in the RTP timestamp field; In a case where the second data packet is a PDCP data packet, and the second data packet does not carry an RTP timestamp field, the second node acquires RTP timestamp information corresponding to the second data packet according to a PDCP sequence number of the second data packet and the stored RTP timestamp information; ​ When the second data packet is a PDCP data packet and the second data packet does not carry an IP identification field, the second node acquires IP identification information corresponding to the second data packet according to a PDCP sequence number of the second data packet. A data transmission apparatus comprises: a first sending module configured to send a first data packet to a second node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of the following: static field information of a real-time transport protocol (RTP) header; static field information of a user datagram protocol (UDP) header; static field information of an internet protocol (IP) header. The apparatus of claim 26, wherein The first data packet further comprises dynamic field negotiation information of the header, and the dynamic field negotiation information of the header comprises at least one of the following: negotiation information of an RTP dynamic field; negotiation information of a UDP dynamic field; negotiation information of an IP dynamic field. The apparatus of claim 26, wherein The first data packet further comprises at least one of the following: first indication information for indicating whether the first data packet and / or a second data packet carries an IP identification field; second indication information for indicating whether the first data packet and / or the second data packet carries a UDP check field; third indication information for indicating a value of an RTP mark field; fourth indication information for indicating whether the first data packet and / or the second data packet carries a static field; fifth indication information for indicating whether the first data packet and / or the second data packet carries an RTP timestamp field; sixth indication information for indicating whether the first data packet and / or the second data packet carries an RTP sequence number field. The apparatus of any one of claims 26 to 28, wherein The apparatus further comprises: a second sending module configured to send a second data packet to the second node, wherein the second data packet does not comprise static field information of a header. The apparatus of claim 29, wherein The second data packet further comprises at least one of the following: seventh indication information for indicating whether the second data packet carries an IP identification field; eighth indication information for indicating whether the second data packet carries a UDP check field; ninth indication information for indicating a value of an RTP mark field; tenth indication information for indicating whether the second data packet carries a static field; eleventh indication information for indicating whether the second data packet carries an RTP timestamp field; twelfth indication information for indicating whether the second data packet carries an RTP sequence number field. A data transmission apparatus comprises: a second receiving module configured to receive a first data packet sent by a first node; wherein the first data packet comprises static field information of a header, and the static field information of the header comprises at least one of the following: static field information of an RTP header; static field information of a UDP header; static field information of an IP header. The apparatus of claim 31, wherein The apparatus further comprises: a third receiving module configured to receive a second data packet sent by the first node, wherein the second data packet does not comprise static field information of a header. The first processing module is configured to recover static field information of a header corresponding to the second data packet according to stored static field information of the header. The apparatus of claim 32, wherein The apparatus further includes: The second processing module is configured to perform at least one of: In a case where the second data packet is a PDCP data packet, obtaining an RTP sequence number corresponding to the second data packet according to a PDCP sequence number of the second data packet; In a case where the second data packet is a PDCP data packet and the second data packet carries an RTP timestamp field, storing RTP timestamp information in the RTP timestamp field; In a case where the second data packet is a PDCP data packet and the second data packet does not carry an RTP timestamp field, obtaining RTP timestamp information corresponding to the second data packet according to a PDCP sequence number of the second data packet and stored RTP timestamp information; In a case where the second data packet is a PDCP data packet and the second data packet does not carry an IP identification field, obtaining IP identification information corresponding to the second data packet according to a PDCP sequence number of the second data packet. A communication device includes a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions being executed by the processor to implement steps of the data transmission method according to any one of claims 1 to 14 or steps of the data transmission method according to any one of claims 15 to 25. A readable storage medium, the readable storage medium storing programs or instructions, the programs or instructions being executed by a processor to implement steps of the data transmission method according to any one of claims 1 to 14 or steps of the data transmission method according to any one of claims 15 to 25.

Images