Data transmission method and apparatus

Abstract

The present application relates to the field of communications. Provided are a data transmission method and apparatus, which are used for improving the efficiency of USB3 data transmission. The method comprises: acquiring a plurality of pieces of data to be sent, wherein the types of the plurality of pieces of data are at least two of the following: a link command, a link management packet (LMP), a transaction protocol (TP), and a deferred data packet header (deferred DPH); and performing encapsulation to obtain a tunnel packet, wherein the tunnel packet comprises a part or all of each piece of data among the plurality of pieces of data, and the tunnel packet further comprises a payload indication, which is used for indicating the type and length of each piece of data comprised in the tunnel packet.

Description

A data transmission method and apparatus Technical Field This application relates to the field of communications, and in particular, to a data transmission method and apparatus. Background Art With the rapid development of communication technologies, there are numerous protocol versions and types for transmitting data (service data or packets after encapsulating service data) in a network. To ensure service continuity, data needs to be transmitted across networks with different protocols, and corresponding different protocols are used in different networks. When data (packets or other formats) transmitted using the universal serial bus (USB) 3 protocol is transmitted to other protocol versions or other types of protocols, or when data is transmitted from other protocol versions or other types of protocols to the USB 3 protocol, the USB adaptation layer needs to convert its protocol format before transmission. However, in the above data transmission process, since the format of the protocol, data, or packet needs to be converted, certain overheads will inevitably be introduced (for example, to support packet encapsulation and restoration, some additional indication information must be transmitted), resulting in bandwidth loss and low data transmission efficiency. Summary of the Invention The data transmission method and apparatus provided in this application improve the data transmission efficiency when performing protocol format conversion. To achieve the above objective, the embodiments of this application adopt the following technical solutions: In a first aspect, a data transmission method is provided. The method may include: obtaining multiple data to be sent; where the types of the multiple data are at least two of the following multiple types: Link Command in USB 3, Link Management Packet (LMP) in USB 3, Transaction Protocol (TP) in USB 3, Deferred Data Packet Header (deferred DPH) in USB 3; encapsulating to obtain a tunnel packet, where the tunnel packet includes part or all of each of the above multiple data. The tunnel packet further includes a payload indication, and the payload indication is used to indicate: the type and length of each data included in the tunnel packet. Through the solution provided in this application, multiple types of data or packets in USB 3 are combined and encapsulated into a tunnel packet, achieving the transmission of multiple USB 3 data or packets at once, and improving the data transmission efficiency. At the same time, a payload indication for indicating the data type and length is carried in the tunnel packet, facilitating the receiving end to accurately parse various types of data from the tunnel packet. In a possible implementation, the above-mentioned multiple data may include: short data that frequently appears in the USB3 protocol. Among them, the frequently appearing short data may refer to: after link establishment to link establishment completion, packets or link commands that are frequently used in the interaction between both sides of the link and whose original length is less than or equal to a threshold value, such as a packet (Packet) or a link command (Link Command). For example, the threshold value may be 32 bytes. By defining the conditions that the data used for combined encapsulation satisfies, the combined transmission of USB3 data is realized, which better improves the transmission efficiency of USB3 data. Among them, link establishment completion means that the Link Training and Status State Machine (LTSSM) is in the U0 state, that is, the normal working state of USB3 data transmission. In another possible implementation, the above-mentioned multiple data may not include the Isochronous Timestamp Packet (ITP). Since the effective length of the ITP packet (the packet length after deleting HPSTART) is 20 bytes, combining it requires using 2-bit payload indication in the tunnel packet to indicate the type and length of the ITP packet. Not combining it can improve the cost performance of combined data transmission. In another possible implementation, the number of bytes occupied by the payload indication in the tunnel packet can be configured according to actual needs, and the embodiments of the present application do not limit it. In another possible implementation, the payload indication can be used to indicate the characteristics of each data included in the tunnel. In another possible implementation, the characteristics of the data may include: the byte length of the data, and / or, the type of the data. In another possible implementation, each data in the multiple data included in the tunnel packet is arranged in the receiving order of the multiple data to ensure the timing of data transmission and avoid too high latency. In another possible implementation, each data in the multiple data included in the tunnel packet is arranged in the sending order of the multiple data to ensure the timing of data transmission and avoid too high latency. In another possible implementation, the number of multiple data encapsulated in the tunnel packet is less than or equal to a first threshold. The data of the first threshold can be configured according to actual needs. The value of the first threshold depends on the length of the payload indication in the tunnel packet. In another possible implementation, the number of multiple data encapsulated in the tunnel packet is less than or equal to 14. In another possible implementation, the total payload length of the tunnel packet is less than or equal to the second threshold number of bytes. The value of the second threshold can be configured according to actual requirements to control the length of the tunnel packet. Exemplarily, the second threshold can be less than or equal to an integer multiple of the minimum packet interval in the protocol used by the tunnel packet, to avoid the tunnel packet being split into multiple packets during transmission, thereby reducing the data packet delay. In another possible implementation, the total payload length of the tunnel packet is less than or equal to 60 bytes. In another possible implementation, before encapsulating to obtain the tunnel packet, the data transmission method provided by this application may further include: determining that the transport layer cannot send the tunnel packet in time, to ensure that data merging does not increase the data transmission delay. In another possible implementation, that the transport layer cannot send the tunnel packet in time can be understood as that there is a tunnel packet waiting to be sent in the transport layer. In another possible implementation, the tunnel packet includes all of each of the above-mentioned multiple data. In another possible implementation, the tunnel packet includes a part of each of the above-mentioned multiple data, and the tunnel packet includes, among the above-mentioned multiple data, the data after deleting the Framing information or the start frame structure for each data. Among them, the Framing information or the start frame structure is invalid content or invalid information in the data. In another possible implementation, the Framing information or the start frame structure is LCSRART, and the data after deleting the Framing information or the start frame structure from the link command is the 4-byte link command data remaining after deleting LCSRART. In another possible implementation, the Framing information or the start frame structure is HPSTART, and the data after deleting the Framing information or the start frame structure from the LMP is the 16-byte LMP data remaining after deleting HPSTART. In another possible implementation, the Framing information or the start frame structure is HPSTART, and the data after deleting the Framing information or the start frame structure from the TP is the 16-byte TP data remaining after deleting HPSTART. In another possible implementation, the Framing information or the start frame structure is HPSTART, and the data after deleting the Framing information or the start frame structure from the postponed data packet header packet is the 16-byte postponed data packet header packet data remaining after deleting HPSTART. In a second aspect, another data transmission method is provided, which may include: receiving a tunnel message, where the tunnel message includes a payload indication for indicating the type and length of each data included in the tunnel message; and parsing the tunnel message according to the type and length of each data indicated by the payload indication, and recovering each data from the payload of the tunnel message. It should be noted that the data transmission method provided in the second aspect is the method of the receiving end corresponding to the data transmission method provided in the first aspect or any possible implementation manner above. Its specific implementation may refer to the first aspect or any possible implementation manner of the first aspect, and will not be elaborated here. In a third aspect, a data transmission device is provided, which may include: an acquisition unit and an encapsulation unit. Among them: The acquisition unit is configured to acquire a plurality of data to be sent. Among them, the types of the plurality of data are at least two of the following: Link Command in USB3, Link Management Protocol (LMP) message in USB3, Transaction Packet (TP) in USB3, and deferred Data Packet Header (DPH) in USB3. The encapsulation unit is configured to encapsulate to obtain a tunnel message, and the tunnel message includes part or all of each data in the plurality of data. The tunnel message includes a payload indication for indicating the type and length of each data included in the tunnel message. Through the solution provided in this application, a plurality of types of data or messages in USB3 are combined and encapsulated into a tunnel message, realizing the transmission of multiple USB3 data or messages at one time, and improving the data transmission efficiency. At the same time, a payload indication for indicating the data type and length is carried in the tunnel message, facilitating the receiving end to accurately parse various types of data from the tunnel message. It should be noted that the data transmission device provided in the third aspect is used to implement the data transmission method provided in the first aspect or any possible implementation manner above. Its specific implementation may refer to the first aspect or any possible implementation manner of the first aspect, and will not be elaborated here. In a fourth aspect, another data transmission device is provided, which may include a receiving unit and a de-encapsulation unit. Among them: The receiving unit is configured to receive a tunnel message, where the tunnel message includes a payload indication for indicating the type and length of each data included in the tunnel message. The de-encapsulation unit is configured to parse the tunnel message according to the type and length of each data indicated by the payload indication, and recover each data from the payload of the tunnel message. In a fifth aspect, a computing device is provided. The computing device includes a memory and at least one processor. The memory is used to store a set of computer instructions. When the processor executes this set of computer instructions, it performs the operations of the method described in the first aspect or the second aspect or any possible implementation manner thereof. In a sixth aspect, a chip is provided, including one or more interface circuits and one or more processors. The interface circuit is used to receive signals from the memory of an electronic device and send the received signals to the processor. The signals include computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device is caused to perform the operation steps of the method described in the first aspect or the second aspect or any possible implementation manner thereof. In a seventh aspect, a computer-readable storage medium is provided, including: computer software instructions. When the computer software instructions run on a computer, the computer is caused to perform the operations of the method described in the first aspect or the second aspect or any possible implementation manner thereof. In an eighth aspect, a computer program product, when running on a computer, causes the computer to perform the operation steps of the method described in the first aspect or the second aspect or any possible implementation manner thereof. In a ninth aspect, a chip is provided. The chip system includes a processor and may also include a memory for implementing the functions in the above method. The chip system may be composed of chips or may include chips and other discrete devices. The solutions provided in the third aspect to the ninth aspect above are used to implement the method provided in the first aspect or the second aspect, and thus can achieve the same beneficial effects as the first aspect or the second aspect, and will not be elaborated here. It should be noted that, under the premise that the solutions do not conflict, any possible implementation manners in each of the above aspects can be combined. Description of the Drawings FIG. 1 is a schematic diagram of the hierarchical structure of a protocol during USB3 data cross-protocol transmission; FIG. 2a is a schematic diagram of the architecture of a multimedia data transmission system provided by an embodiment of the present application; FIG. 2b is a schematic diagram of the architecture of another multimedia data transmission system provided by an embodiment of the present application; FIG. 3 is a schematic diagram of the structure of a USB3 tunnel message; FIG. 4 is a schematic diagram of another USB3 tunnel message structure; FIG. 5 is a schematic diagram of the format of an isochronous timestamp message; FIG. 6 is a schematic diagram of a scenario of an encapsulated message; FIG. 7 is a schematic diagram of the structure of a computing device provided by an embodiment of the present application; FIG. 8 is a schematic flowchart of a data transmission method provided by an embodiment of the present application; FIG. 9 is a schematic diagram of the format of a tunnel message provided by an embodiment of the present application; FIG. 10 is a schematic diagram of the format of a tunnel message provided by an embodiment of the present application; FIG. 11 is a schematic diagram of the format of another tunnel message provided by an embodiment of the present application; FIG. 12 is a schematic diagram of the format of yet another tunnel message provided by an embodiment of the present application; FIG. 13 is a schematic diagram of the format of yet another tunnel message provided by an embodiment of the present application; FIG. 14 is a schematic diagram of the format of a tunnel message provided by an embodiment of the present application; FIG. 15 is a schematic structural diagram of a data transmission device provided by an embodiment of the present application; FIG. 16 is a schematic structural diagram of another data transmission device provided by an embodiment of the present application. Detailed implementation manners In the embodiments of the present application, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, terms such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and roles. Those skilled in the art can understand that the terms "first" and "second" do not limit the quantity and execution order, and the terms "first" and "second" do not necessarily limit being different. There is no sequential order or size order between the technical features described by the "first" and "second". In the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, using words such as "exemplary" or "for example" aims to present relevant concepts in a specific manner for easy understanding. In the embodiments of the present application, at least one can also be described as one or more, and multiple can be two, three, four or more, which is not limited in the present application. In addition, the network architectures and scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation to the technical solutions provided by the embodiments of the present application. Those skilled in the art know that with the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems. For ease of understanding, first, the nouns involved in the embodiments of the present application are explained. The USB3 protocol is a USB specification, including versions such as USB 3.0, USB 3.1, and USB 3.2. The USB3 protocol is a USB specification, including versions such as USB 3.0, USB 3.1, and USB 3.2. The data can refer to data in a message format or other formats, and the present application does not limit this. USB3 data refers to data (such as messages or commands, etc.) transmitted using the USB3 protocol. When USB3 data (data using the USB3 protocol) is transmitted to a network using other bus protocols (such as the unified multimedia interconnect bus protocol, or other bus protocols with a higher version than USB3), other protocols need to carry the characteristics of the USB3 protocol. Figure 1 illustrates the layering in each protocol when USB3 data is transmitted across protocols. As shown in Figure 1, the USB3 adaptation layer is located between the USB3 link layer and the transport layer of other protocols. Among them, the USB3 adaptation layer on the sending side is responsible for converting the data sent by the USB3 link layer into data in other protocol formats (messages or other formats) and sending it to the transport layer of other protocols. The USB3 adaptation layer on the receiving side restores the data received from the transport layer of other protocols into USB3 data and reports it to the USB3 link layer. In the protocol layering architecture shown in Figure 1, for the transmission process between the USB3 adaptation layer and the USB3 application layer (in the sending or receiving direction), referring to the USB3 protocol, the present application will not elaborate. In the layering architecture shown in Figure 1, during the process of the USB3 adaptation layer sending data downward (to the transport layer of other protocols), there is a large amount of data and messages with short lengths interacting, such as a large number of messages or link commands with short lengths will be used. For example, for each transmission of a TP, DP, or ITP by the USB3 protocol layer, the link layer needs to use link commands (Link CMD) such as LGOOD, LBAD, and LCRD for flow control (Flow Control). A large number of messages with short lengths will all introduce additional overheads brought by themselves (for example, in order to support message encapsulation and restoration, some additional indication information must be transmitted), resulting in a relatively large proportion of bandwidth loss during the USB3 data transmission process. Based on this, the present application provides a data transmission method, which aggregates and combines multiple short data into tunnel messages for transmission to improve data transmission efficiency. Next, in combination with the accompanying drawings, the solutions provided by the embodiments of the present application will be specifically described. Figure 2a illustrates a multimedia data transmission system. As shown in Figure 2a, the multimedia data transmission system may include a source device 201, a destination device 202, and a data server 203. Among them, the source device 201 and the destination device 202 can be directly connected or connected through a routing device (this scenario is not shown in Figure 2a), and the layering architecture of the multimedia data transmission system can be as shown in Figure 1. In the multimedia data transmission system shown in FIG. 2a, the source device 201 obtains multimedia data from the data server 203 through the network and transmits the multimedia data to the sink device 202. In one scenario, either the source device 201 or the sink device 202 is a unified multimedia interconnection device with a unified multimedia interconnection interface, and the other is a third-party protocol (such as the USB3 protocol) device relative to the unified multimedia interconnection, realizing data interaction between the third-party protocol device and the unified multimedia interconnection device. In one scenario, the source device 201 can be a set-top box device. The sink device 202 can be a device with a screen. Exemplarily, the set-top box device can obtain multimedia data from the data server 203 through the network via a router, a switch, or other network devices. Exemplarily, the set-top box device can also be referred to as a digital video conversion box (set top box, STB), or an on-board box, or others. The set-top box device is a device that connects a multimedia playback device and an external signal source. The specific product form of the set-top box device is not limited in this application. The sink device 202 can be a smart TV, a tablet, a smart screen, or others, for receiving and playing multimedia data. The specific product form of the sink device 202 is not limited in this application. The data server 203 can be an application server or other types of servers, for providing multimedia services (such as video, audio, or other services). The specific product form, deployment method, and deployment location of the data server 203 are not specifically limited in this application. In a possible implementation, the internal architecture of the multimedia data transmission system shown in FIG. 2a can be as shown in FIG. 2b. As shown in FIG. 2b, the source device 201 and the sink device 202 include a router and a transceiver device, and the router includes an adapter and a port. Among them, the router can encapsulate the data generated by external components into a unified multimedia interconnection message through the adapter, forming a unified multimedia interconnection service flow and forwarding it to the port, and the port sends it to the router of the peer device. The router of the peer device obtains the unified multimedia interconnection service flow restored by the port, forwards it to the adapter for processing, and the adapter processes it into data and sends it to the external components. Exemplarily, when the terminal device is a third-party protocol device, the adapter in the router can be a third-party protocol adapter (such as a USB3 adapter). The third-party protocol adapter receives third-party protocol data from the third-party protocol component, encapsulates it into a USB3 tunnel packet (specifically, it can be a unified multimedia interconnection protocol packet), forms a traffic flow, and sends it to the corresponding port, which forwards it to the router of the peer device. The router of the peer device obtains the traffic flow restored by the port (such as a unified multimedia interconnection traffic flow), forwards it to the corresponding third-party protocol adapter for processing. After the third-party protocol adapter processes it into third-party protocol data, it is sent to the third-party protocol component. Exemplarily, the USB3 tunnel packet (also referred to as a tunnel packet) encapsulated by the USB3 adapter consists of two parts: a packet header and a packet payload. Exemplarily, the basic structure of the USB3 tunnel packet can be as shown in Figure 3. The length of the packet header can be fixed at 4 bytes, the length of the packet payload is at least 4 bytes, and the maximum can support 508 bytes. In the unified multimedia interconnection interface protocol, it is stipulated that the packet payload of the tunnel packet must be 4-byte aligned. When the length of the data to be transmitted does not meet the 4-byte alignment, padding is filled starting from the lowest byte of the last double word (Dword), with a maximum of 3 bytes of padding filled. In the packet header of the USB3 tunnel packet shown in Figure 3, the Type field in the tunnel packet header is used to indicate the type of the tunnel packet, and its definition can be as shown in Table 1 below. The ShuttleID (virtual channel identifier) field, Length field, D (data packet flag, 1 for data packet, 0 for management packet) field, and ECC (Error Checking and Correcting) field are defined in the transport layer of the USB3 protocol and will not be elaborated here. Table 1 The packet payload of the USB3 tunnel packet is used to encapsulate the data exchanged between the local USB3 link layer and the peer USB3 link layer. Some of the data in the exchanged data is deleted by the USB3 adapter on the sending side (the component responsible for the USB3 adaptation layer function). The USB3 adapter that receives the tunnel packet automatically generates this part of the content (the content deleted by the sending-side adapter) according to the type of the USB3 data or packet, such as the framing information of the Link Command and the specific code patterns in the Ordered Set, etc., to improve the bandwidth utilization rate. The Type field in the header of the USB3 tunnel packet indicates the type of the USB3 packet that generates the USB3 tunnel packet. The following examples in this application describe the formats of several types of tunnel packets: When the Type field in the header is Link Command / LMP / TP / deferred DPH, the USB3 tunnel packet encapsulates one or more link commands, link management packets, transaction packets, and deferred data packet header packets. The format of this type of packet can be as shown in Figure 4. The packet payload is, in sequence, the Payload Indicator field, the ECC field, and the Payload Body field. In the packet format illustrated in Figure 4, the definition of the ECC field can be the same as that of the ECC in the header, and the definition of the Payload Indicator field can be as shown in Table 2 below. Table 2 For example, in the Payload Indicator, bit[0]=0 indicates that in the Payload Body of the USB3 tunnel packet, the subtype of the first USB3 data or packet is Link Command, and the payload length is 4 bytes; bit[1]=1 indicates that in the Payload Body of the USB3 tunnel packet, the subtype of the second USB3 data or packet is LMP / TP / deferred DPH, and the payload length is 16 bytes, and so on. Among them, the length of the Payload Body depends on the Length field in the header, and the length of the Payload Body determines which bits in the Payload Indicator are valid. Specifically, the Payload Body field represents the link command, link management packet, transaction packet, or deferred data packet header packet body after removing the Framing information or the start frame structure. Exemplarily, the total length of the Payload Body field can not exceed 56 bytes. When the Type field in the header is ITP, the tunnel packet encapsulates an isochronous timestamp packet. The format of the isochronous timestamp packet can be as shown in Figure 5. The length of its packet payload is 24 bytes, which are, in sequence, a 16-byte ITP field and an 8-byte timestamp field. In the packet format illustrated in Figure 5, the ITP field is the content of the USB3 ITP packet, and its definition can refer to the USB3 protocol, which will not be elaborated here. The timestamp field represents the data for time synchronization, which is not limited in the embodiments of this application. When the USB3 adapter encapsulates USB3 Link Command, LMP, TP, ITP, and DP into USB3 tunnel packets of other protocols, it removes the Framing information or the start frame structure (invalid or useless data in the packet), and then fills the USB3 data or the data structure of the packet into the Payload part of the USB3 tunnel packet. For different types of USB3 tunnel packets, the removed USB3 Framing information or start frame structure is different, as shown in Table 3 below. Table 3 As shown in Figure 6, taking the DP (DPH + DPP) packet as an example, the process of the USB3 adapter encapsulating the DP packet to obtain the USB3 tunnel packet is described. The process of encapsulating other types of USB3 packets into USB3 tunnel packets will not be described one by one. The USB3 adapter deletes the HPSTART ordered set in the DP packet header and the DPPSTART ordered set in the DP packet payload. The remaining packet header, packet payload, and the packet payload end frame structure DPPEND are used together as the payload of the tunnel packet, and a tunnel packet header is added to encapsulate it into a DP tunnel packet of other protocols. Exemplarily, the DP packet payload can have two end frame structures, namely DPPEND and DPPABORT. In Figure 6, DPPEND is taken as an example for illustration, which does not constitute a specific limitation. On the one hand, an embodiment of the present application provides a schematic structural diagram of a computing device 70. The computing device 70 can implement the functions of the source device 201 or the sink device 202 schematically shown in Figure 2a. As shown in Figure 7, the computing device 70 may include a processor 7010, a bus 7020, a memory 7030, and a communication interface 7040. The processor 7010, the memory 7030, and the communication interface 7040 are connected through the bus 7020. It should be understood that in this embodiment, the processor 7010 may be a central processing unit (CPU), and the processor 7010 may also be other general-purpose processors, digital signal processors (DSP), (application-specific integrated circuit, ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor 7010 may also be a graphics processing unit (GPU), a neural network processing unit (NPU), a microprocessor, an ASIC, or one or more integrated circuits for controlling the execution of the program of the solution of this application. The communication interface 7040 is used to implement the communication between the computing device 70 and external devices or components. The bus 7020 may include a path for transmitting information between the above components (such as the processor 7010 and the memory 7030). In addition to the data bus, the bus 7020 may also include a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, all kinds of buses are labeled as the bus 7020 in the figure. The bus 7020 may be a peripheral component interconnect express (PCIe) bus, or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 7020 may be divided into an address bus, a data bus, a control bus, etc. As an example, the computing device 70 may include multiple processors. The processor may be a multi-CPU processor. Here, the processor may refer to one or more devices, circuits, and / or computing units for processing data (such as computer program instructions). It should be noted that in FIG. 7, only the case where the computing device 70 includes 1 processor 7010 and 1 memory 7030 is taken as an example. Here, the processor 7010 and the memory 7030 are respectively used to indicate a type of device or component. In a specific embodiment, the number of each type of device or component may be determined according to service requirements. The memory 7030 can be a volatile memory pool or a non-volatile memory pool, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM). Exemplarily, by running or executing software programs and / or modules stored in the memory 7030, the processor 7010 can perform the following functions: Obtain a plurality of data to be sent; wherein, the types of the plurality of data are at least two of the following: Link Command, LMP message, TP message, deferred DPH message. Encapsulate to obtain a tunnel message, and the tunnel message includes part or all of each of the above plurality of data. The tunnel message also includes a payload indication, and the payload indication is used to indicate: the type and length of each data included in the tunnel message. On the other hand, an embodiment of the present application provides a data transmission method, which is applied to the source device 201 or the sink device 202 in the multimedia transmission system shown in FIGS. 2a or 2b, or the chip in the source device 201, or the chip in the sink device 202, and this method can be executed by a computing device. As shown in FIG. 8, the data transmission method provided by the embodiment of the present application can include: S801. The computing device obtains a plurality of data to be sent. Specifically, the operation of S801 can be performed by the USB3 adaptation layer in the computing device. The data to be sent is stored in the cache, and the computing device can read it from the cache to obtain the data to be sent. In a possible implementation, the types of the multiple data are at least two of the following multiple types: Link Command, Link Management Packet (LMP), Transaction Packet (TP), and Delayed Data Packet Header Packet. In a possible implementation, the types of the multiple data are one or more of the following multiple types: Link Command, Link Management Packet (LMP), Transaction Packet (TP), and Delayed Data Packet Header Packet. In a possible implementation, the above-mentioned multiple data can be short data that frequently appears in the USB3 protocol. Among them, the short data that frequently appears can refer to: after link establishment to link establishment completion, the packets (Packets) or link commands (Link Commands) that are frequently used in the interaction between the two parties of the link and whose original length is less than or equal to the threshold value. Link establishment completion means that the LTSSM is in the U0 state, that is, the normal state of USB3 data transmission. Among them, the above-mentioned threshold value can be configured according to actual needs, and the embodiments of the present application do not limit this. For example, the threshold value can be 32 bytes. In another possible implementation, the above-mentioned multiple data may not include ITP packets. Since the effective length of the ITP packet is 20 bytes, merging it requires using 2-bit payload indication in the USB3 tunnel packet to indicate the type and / or length of the ITP packet. Not merging it can improve the cost performance of data merged transmission. In a possible implementation, the number of the above-mentioned multiple data (the multiple data for merging) is less than or equal to a first threshold value. The value of the first threshold can be determined according to actual needs, and the embodiments of the present application do not limit this. Exemplarily, the value of the first threshold can be related to the data length of the protocol used by the merged tunnel packet, that is, the tunnel packet obtained by merging less than or equal to the second threshold number of first data that meet the first condition is less than or equal to the length of the data packet of the protocol used by the tunnel packet. In a possible implementation, the number of the above-mentioned multiple data (the multiple data for merging) is less than or equal to 14. S802. The computing device encapsulates to obtain a tunnel packet, and the tunnel packet includes part or all of each of the above-mentioned multiple data. The tunnel packet also includes a payload indication, and the payload indication is used to indicate: the type and length of each data included in the tunnel packet. Specifically, the operation of S802 can be performed by the USB3 adaptation layer in the computing device. In S802, the computing device combines the multiple pieces of data to be sent obtained in S801 to generate a tunnel message using a protocol other than the USB3 protocol, so that the payload of the tunnel message includes some or all of each piece of data among the multiple pieces of data. Specifically, the tunnel message encapsulated in S801 may include the valid data of each piece of data among the multiple pieces of data, and the valid data is included in the payload of the tunnel message. In one possible implementation, the valid data in the data may include the data itself. Then, the tunnel message includes all the content of each piece of data among the multiple pieces of data. In another possible implementation, the tunnel message includes a part of each piece of data among the multiple pieces of data, and the tunnel message includes, among the multiple pieces of data, the data after deleting the Framing information or the start frame structure of each piece of data. Exemplarily, the Framing information or the start frame structure can be understood as invalid data / useless data. For example, the Framing information or the start frame structure may be the removed USB3 Framing information illustrated in Table 3 above. Of course, the content of the Framing information or the start frame structure of the data can be configured according to actual needs, and the embodiments of the present application do not limit this. In one possible implementation, the multiple pieces of data included in the tunnel message are arranged in the order of reception of the multiple pieces of data. The order of the data is ensured, that is, the data or message received first must be sent first, and out-of-order is not allowed. In one possible implementation, the multiple pieces of data included in the tunnel message are arranged in the order of transmission of the multiple pieces of data. The order of the data is ensured, that is, the data or message received first must be sent first, and out-of-order is not allowed. In one possible implementation, the total length of the payload of the tunnel message is less than or equal to the second threshold number of bytes. The value of the second threshold can be configured according to actual needs to control the length of the tunnel message. Exemplarily, the second threshold may be less than or equal to an integer multiple of the minimum packet interval in the protocol used by the tunnel message, so as to avoid the tunnel message being split into multiple packets during transmission, thereby reducing the packet delay. In one possible implementation, the total length of the payload of the tunnel message is less than or equal to 60 bytes. For example, FIG. 9 illustrates a format of a tunnel message, which includes a message header and a payload of the tunnel message, and the payload part includes multiple USB3 data in the order of reception. Further, the payload indication included in the tunnel packet can be used to indicate the characteristics of each piece of data included in the tunnel packet. The characteristics of the data included in the tunnel packet are used by the USB3 adaptation layer at the receiving end to parse the data from the tunnel packet, determine the type of the data, and then recover the data for further transmission in the USB3 protocol. In a possible implementation, the characteristics of the data include the byte length of the data, and / or the type of the data. Exemplarily, the payload indication can be included in the header of the tunnel packet. For example, the payload indication can refer to the specific implementation of the Payload Indicator shown in FIG. 4 and Table 2 above, and will not be elaborated here. Further, the number of types of the lengths of the valid data included in the tunnel packet can be more than three. Correspondingly, the number of bits occupied by the payload indication will also increase. The reserved fields in the header of the tunnel packet (for example, in the format shown in FIG. 4, bits 6 to 15 and bits 30 and 31 in the header) can be extended as the payload indication. In a possible implementation, the computing device can execute the operation of S802 in real time. In another possible implementation, the computing device can execute the operation of S802 when the transport layer of the protocol adopted by the tunnel packet meets the condition. This condition is used to indicate that the transport layer cannot send data in a timely manner. Exemplarily, the above condition can include that there is data waiting to be sent. In another possible implementation, before executing S802, the computing device determines that the transport layer cannot send the tunnel packet in a timely manner, and then executes the operation of S802. Exemplarily, determining that the transport layer cannot send the tunnel packet in a timely manner is equivalent to that there is data waiting to be sent. Through the solution provided by this application, multiple types of data or packets in USB3 are combined and encapsulated into a tunnel packet, realizing the one-time transmission of multiple USB3 data or packets, and improving the data transmission efficiency. At the same time, a payload indication for indicating the data type and length is carried in the tunnel packet, which facilitates the receiving end to accurately parse various types of data from the tunnel packet. Further, the USB3 adaptation layer on the sending side executes the processes described in S801 and S802 above, encapsulates multiple data into tunnel packets, and sends them to the transport layer of other protocols. After that, the tunnel packets continue to be transmitted according to this protocol (for example, transmitted in the logical layer - electrical layer - electrical layer - logical layer - transport layer of the hierarchical architecture shown in FIG. 1) until they are transmitted to the USB3 adaptation layer on the receiving side. After the USB3 adaptation layer on the receiving side restores the USB3 data or packets encapsulated in the tunnel packets, they continue to be transmitted in the subsequent layers of USB3 (for example, transmitted in the USB3 link layer - USB3 protocol layer - USB3 application layer of the hierarchical architecture shown in FIG. 1). On the other hand, an embodiment of the present application further provides another data transmission method, which may include: receiving a tunnel packet, where the tunnel packet includes a payload indication for indicating the type and length of each data included in the tunnel packet; and parsing the tunnel packet according to the type and length of each data indicated by the payload indication to restore each data from the payload of the tunnel packet. Exemplarily, the process of the USB3 adaptation layer on the receiving side parsing the tunnel packet to obtain data may include: the USB3 adaptation layer on the receiving side first parses the payload indication in the tunnel packet (position determination, definition determination), then determines the type and data length of the data sequentially included in the payload of the tunnel packet according to the content indicated by the payload indication, and then splits the payload part of the tunnel packet according to the respective data lengths indicated by the payload indication. If all of the USB3 data is included in the tunnel packet, the split data is the restored USB3 data; if the data in the tunnel packet is the USB3 data after deleting the Framing information or the start frame structure, then in each of the split data, add the Framing information or the start frame structure corresponding to each data type indicated by the payload indication (such as the content shown in Table 3 above) to obtain multiple restored data. Exemplarily, when the USB3 adapter on the receiving side receives a tunnel packet and the data parsed and obtained from the payload of the tunnel packet is sequentially: 4-byte Link Command data, 16-byte LMP data, 16-byte TP data, and 16-byte deferred DPH data, the USB3 adapter on the receiving side first generates an LCSTART frame structure and then reports it to the USB3 link layer together with the 4-byte Link Command data; then, generates an HPSTART frame structure and then reports it to the USB3 link layer together with the 16-byte LMP data; then, generates an HPSTART frame structure and reports it to the USB3 link layer together with the 16-byte TP data; finally, generates an HPSTART frame structure and then reports it to the USB3 link layer together with the 16-byte deferred DPH data. The following uses specific examples to illustrate link commands (Link Command), link management packets (LMP), transaction packets (TP), deferred data packet header packets (deferred DPH), and the merging process of these data. When the USB3 link layer instructs to send a link command (Link Command), the USB3 adapter first deletes the starting frame structure of the link command, i.e., LCSTART, and then uses the remaining 4-byte Link Command data to encapsulate the tunnel packet. Link commands can be combined with link management packets (LMP), transaction packets (TP), and deferred data packet header packets (deferred DPH) to merge multiple packets into one tunnel packet. An unmerged link command tunnel packet has the format shown in Figure 10, where the detailed definition of Link Command refers to the USB3.2 protocol. When the USB3 adapter receives a link command, it first generates the LCSTART frame structure and then reports it to the USB3 link layer together with the 4-byte Link Command data. When the USB3 link layer instructs to send a link management packet (LMP), the USB3 adapter first deletes the starting frame structure of the packet, i.e., HPSTART, and then uses the remaining 16-byte LMP data to encapsulate the tunnel packet. Link management packets can be combined with link commands (Link Command), transaction packets (TP), and deferred data packet header packets (deferred DPH) to merge multiple packets into one tunnel packet. An unmerged LMP tunnel packet has the format shown in Figure 11, where the detailed definition of LMP refers to the USB3.2 protocol. When the USB3 adapter receives a link management packet, it first generates the HPSTART frame structure and then reports it to the USB3 link layer together with the 16-byte LMP data. When the USB3 link layer instructs to send a transaction packet (TP), the USB3 adapter determines that the transaction packet (TP) first deletes the starting frame structure of the packet, i.e., HPSTART, and then uses the remaining 16-byte TP data to encapsulate the tunnel packet. Transaction packets can be combined with link commands (Link Command), link management packets (LMP), and deferred data packet header packets (deferred DPH) to merge multiple packets into one tunnel packet. An unmerged TP tunnel packet has the format shown in Figure 12, where the detailed definition of TP refers to the USB3.2 protocol. When the USB3 adapter receives a transaction packet, it first generates an HPSTART frame structure and then reports it to the USB3 link layer together with 16 bytes of TP data. When the USB3 link layer instructs to send a deferred DPH (deferred data packet header), the USB3 adapter first deletes the starting frame structure of the packet, i.e., HPSTART, and then uses the remaining 16 bytes of deferred DPH data to encapsulate the tunnel packet. The deferred DPH can be combined with link commands, link management packets (LMP), and transaction packets (TP) into one tunnel packet. A non - merged deferred DPH tunnel packet has the format shown in Figure 13. For the detailed definition of deferred DPH, refer to the USB3.2 protocol. When the USB3 adapter receives a deferred DPH, it first generates an HPSTART frame structure and then reports it to the USB3 link layer together with 16 bytes of deferred DPH data. When the USB3 adapter combines multiple link commands, link management packets (LMP), transaction packets (TP), and deferred DPH into one tunnel packet, all of the following requirements must be met: 1) Only when the transport layer of the unified multimedia interconnection cannot send the USB3 tunnel packet in time, is it allowed to combine multiple data or packets cached in the USB3 adapter and waiting to be sent into one tunnel packet. 2) The original sending order of the USB3 data or packets must be ensured, and out - of - order is not allowed. 3) The number of combined USB3 data or packets does not exceed 14. 4) The total payload length of the combined tunnel packet does not exceed 60 bytes. The format of combining multiple link commands and packets into one tunnel packet can be as shown in Figure 14. In the tunnel packet shown in Figure 14, there are 14 valid data. Each bit in the payload indication part is used to indicate the length of the valid data of one data, and two types of data lengths can be indicated. For example, bit

[0016] = 0 is used to indicate that the length of the valid data of the first data in the payload is 4 bytes, and bit

[0017] = 0 is used to indicate that the length of the valid data of the second data in the payload is 16 bytes. The above has introduced the solution provided by the embodiments of the present invention mainly from the perspective of the working principle of the computing device. It can be understood that in order to implement the above functions, the computing device and the like include the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily realize that the present invention can be implemented in the form of hardware or a combination of hardware and computer software in combination with the units and algorithm steps of each example described in the embodiments disclosed herein. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention. The embodiments of the present invention can divide the functional modules of the computing device and the like according to the above method examples. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiments of the present invention is illustrative, only a logical function division, and there can be other division methods in actual implementation. In the case of dividing each functional module corresponding to each function, FIG. 15 illustrates a data transmission device 150 provided by an embodiment of the present application, and the data transmission device 150 is used to implement the functions of the computing device in the above method embodiment. As shown in FIG. 15, the data transmission device 150 may include: an acquisition unit 1501 and a packaging unit 1502. The acquisition unit 1501 is used to execute the process S801 in FIG. 8; the packaging unit 1502 is used to execute the process S802 in FIG. 8. Among them, all relevant contents of each step involved in the above method embodiment can be cited in the function description of the corresponding functional module, and will not be repeated here. In the case of using an integrated unit, as shown in FIG. 16, it is a data transmission device 160 provided by an embodiment of the present application, which is used to implement the functions of the computing device in the above embodiment. The data transmission device 160 includes a processing module 1601 and a communication module 1602. The processing module 1601 is used to control and manage the actions of the data transmission device 160, and the communication module 1602 is used to communicate with other devices. For example, the processing module 1601 is used to execute S801 or S802 in FIG. 8; the communication module 1602 is used for the data transmission device 160 to interact with other devices. The data transmission device 160 may further include a storage module 1603, which is used to store the program code and data of the data transmission device 160. Among them, the processing module 1601 may be the processor 7010 in the physical structure of the computing device 70 shown in FIG. 7, and may be a processor or a controller. For example, it may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in connection with the disclosure of the present application. The processing module 1601 may also be a combination that implements computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The communication module 1602 may be the communication interface 7040 in the physical structure of the computing device 70 shown in FIG. 7. The communication module 1602 may be a communication port, or may be a transceiver, a transceiver circuit, or a communication interface, etc. Alternatively, the above communication interface may implement communication with other devices through the above elements having transceiver functions. The above elements having transceiver functions may be implemented by an antenna and / or a radio frequency device. The storage module 1603 may be the memory 7030 in the physical structure of the computing device 70 shown in FIG. 7. As described above, the data transmission devices 150 and 160 provided in the embodiments of the present application can be used to implement the functions of the computing device in the above embodiments of the present application. For the sake of convenience of description, only the parts related to the embodiments of the present application are shown. For the specific technical details not disclosed, please refer to the various embodiments of the present application. On the other hand, the embodiments of the present application provide a data transmission system, including the above data transmission device 150 or data transmission device 160. As another form of this embodiment, a computer-readable storage medium is provided, on which instructions are stored, and when the instructions are executed, the data transmission method in the above method embodiment is executed. As another form of this embodiment, a computer program product including instructions is provided. When the computer program product runs on a computer, the computer is caused to execute the data transmission method in the above method embodiment when executed. As another form of this embodiment, a chip is provided, including one or more interface circuits and one or more processors; the interface circuit is configured to receive a signal from the memory of the electronic device and send the received signal to the processor, and the signal includes computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device is caused to execute the operation steps of the method described in the first aspect or any possible implementation manner above. Another embodiment of the present application provides a chip system, which includes a processor for implementing the technical method of the embodiments of the present invention. In a possible design, the chip system further includes a memory for storing the necessary program instructions and / or data of the embodiments of the present invention. In a possible design, the chip system further includes a memory for the processor to call the application program code stored in the memory. The chip system may be composed of one or more chips, or may include chips and other discrete devices. The embodiments of the present application do not make specific limitations on this. Those skilled in the art should easily realize that, in combination with the units and method steps of each example described in the embodiments disclosed in the present application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application scenario and design constraints of the technical solution. The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software When implemented, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the processes or functions described in the embodiments of the present invention of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that contains a set of one or more available media. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium. The semiconductor medium can be an SSD. As mentioned above, the above are only the specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A data transmission method, characterized in that, the method includes: Obtaining a plurality of data to be sent; wherein, the types of the plurality of data are at least two of the following: Link Command in Universal Serial Bus (USB) 3, Link Management Protocol (LMP) message in USB 3, Transaction Packet (TP) in USB 3, and deferred Data Packet Header (deferred DPH) in USB 3; Encapsulating to obtain a tunnel packet, the tunnel packet including part or all of each of the plurality of data; the tunnel packet includes a payload indication, and the payload indication is used to indicate: the type and length of each data included in the tunnel packet.

2. The method according to claim 1, characterized in that, the plurality of data included in the tunnel packet are arranged in the order of reception of the plurality of data.

3. The method according to claim 1 or 2, characterized in that, the number of the plurality of data is less than or equal to 14.

4. The method according to any one of claims 1-3, characterized in that, the total payload length of the tunnel packet is less than or equal to 60 bytes.

5. The method according to any one of claims 1-4, characterized in that, before encapsulating to obtain the tunnel packet, the method further includes: Determining that the transport layer cannot send the tunnel packet in time.

6. The method according to any one of claims 1-5, characterized in that, the tunnel packet includes part of each of the plurality of data, and the tunnel packet includes, among the plurality of data, the data remaining after deleting the Framing information or start frame structure of each data.

7. The method according to claim 6, characterized in that, the Framing information or start frame structure is LCSRART, and the data remaining after deleting the Framing information or start frame structure from the Link Command is the 4-byte Link Command data remaining after deleting LCSRART; or, the Framing information or start frame structure is HPSTART, and the data remaining after deleting the Framing information or start frame structure from the Link Management Message LMP is the 16-byte LMP data remaining after deleting HPSTART; or, the Framing information or start frame structure is HPSTART, and the data remaining after deleting the Framing information or start frame structure from the Transaction Packet TP is the 16-byte TP data remaining after deleting HPSTART; or, the Framing information or start frame structure is HPSTART, and the data remaining after deleting the Framing information or start frame structure from the deferred Data Packet Header is the 16-byte deferred Data Packet Header data remaining after deleting HPSTART.

8. A data transmission device, characterized in that, the device includes: An acquisition unit, configured to acquire a plurality of data to be sent; wherein, the types of the plurality of data are at least two of the following: Link Command in Universal Serial Bus (USB) 3, Link Management Protocol (LMP) message in USB 3, Transaction Packet (TP) in USB 3, and deferred Data Packet Header (DPH) in USB 3; An encapsulation unit, configured to encapsulate to obtain a tunnel packet, where the tunnel packet includes part or all of each of the plurality of data; a payload indication is included in the tunnel packet, and the payload indication is used to indicate: the type and length of each data included in the tunnel packet.

9. The apparatus according to claim 8, wherein, the plurality of data included in the tunnel packet are arranged in the order of reception of the plurality of data.

10. The apparatus according to claim 8 or 9, wherein, the number of the plurality of data is less than or equal to 14.

11. The apparatus according to any one of claims 8-10, wherein, the total payload length of the tunnel packet is less than or equal to 60 bytes.

12. The apparatus according to any one of claims 8-11, wherein, the apparatus further includes a determination unit, configured to: before encapsulating to obtain the tunnel packet, determine that the transport layer cannot send the tunnel packet in time.

13. The apparatus according to any one of claims 8-12, wherein, the tunnel packet includes part of each of the plurality of data, and in the plurality of data included in the tunnel packet, the data after deleting the Framing information or start frame structure of each data.

14. The apparatus according to claim 13, wherein, the Framing information or start frame structure is LCSRART, and the data of the link command after deleting the Framing information or start frame structure is the 4-byte link command data remaining after deleting LCSRART; or, the Framing information or start frame structure is HPSTART, and the data of the Link Management Message (LMP) after deleting the Framing information or start frame structure is the 16-byte LMP data remaining after deleting HPSTART; or, the Framing information or start frame structure is HPSTART, and the data of the Transaction Packet (TP) after deleting the Framing information or start frame structure is the 16-byte TP data remaining after deleting HPSTART; or, the Framing information or start frame structure is HPSTART, and the data of the deferred Data Packet Header after deleting the Framing information or start frame structure is the 16-byte deferred Data Packet Header data remaining after deleting HPSTART.

15. A computing device, wherein, The computing device includes a memory and at least one processor, the memory being configured to store a set of computer instructions; when the processor executes the set of computer instructions, the operations of the method according to any one of claims 1-7 above are performed.

16. A chip, characterized in that it includes one or more interface circuits and one or more processors; the interface circuit is configured to receive a signal from the memory of the electronic device and send the signal to the processor, the signal including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device is caused to perform the operation steps of the method according to any one of claims 1-7.

17. A computer-readable storage medium, characterized in that it includes: computer software instructions; when the computer software instructions run on a computer, the computer is caused to perform the operation steps of the method according to any one of claims 1-7 above.

18. A computer program product, characterized in that the computer program product contains a software program, and when the software program is executed by a computer or a processor, the computer or the processor is caused to perform the operation steps of the method according to any one of claims 1-7.

Images