WO2010020197A1 - 一种数据的传输方法、通信设备及通信*** - Google Patents

一种数据的传输方法、通信设备及通信*** Download PDF

Info

Publication number
WO2010020197A1
WO2010020197A1 PCT/CN2009/073439 CN2009073439W WO2010020197A1 WO 2010020197 A1 WO2010020197 A1 WO 2010020197A1 CN 2009073439 W CN2009073439 W CN 2009073439W WO 2010020197 A1 WO2010020197 A1 WO 2010020197A1
Authority
WO
WIPO (PCT)
Prior art keywords
gtp
user
header
radio service
tunneling protocol
Prior art date
Application number
PCT/CN2009/073439
Other languages
English (en)
French (fr)
Inventor
赖志昌
杨义成
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2010020197A1 publication Critical patent/WO2010020197A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a data transmission method, a communication device, and a communication system.
  • Tunneling is a way of transferring data between networks by using the infrastructure of the Internet.
  • the data (or load) passed using the tunnel can be a data frame or packet of a different protocol.
  • the tunneling protocol repackages the data frames or packets of other protocols and then sends them through the tunnel.
  • the new frame header provides routing information to pass the encapsulated payload data over the Internet.
  • GTP General Packet Radio Service
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • Good services such as IP (Intemet Protocol) grouping.
  • the wireless access side device When the data is transmitted on the IP network by using the UDP/IP path protocol, the wireless access side device needs to re-encapsulate the data packet sent by the terminal to form a user-level GPRS Tunneling Protocol (GTP-U) data packet.
  • GTP-U user-level GPRS Tunneling Protocol
  • the IP network is a PPP (Point-to-Point Protocol) link
  • the formed GTP-U data packet is shown in FIG. 1.
  • its transmission overhead includes GTP-U header, transport network layer UDP, transport network layer IP, and PPP header overhead, which are 43 or 47 bytes in total.
  • the transmission efficiency For the average data packet length of the ordinary data service is 286 bytes, the transmission efficiency is 87.32%, and the transmission overhead at this time is 43 bytes.
  • the size of the valid data is about the transmission cost. It is 40 bytes, or smaller.
  • the transmission overhead is 43 bytes, its transmission efficiency is up to 48.19%.
  • the PPP Point to Point Protocol
  • the control domain compression ACFC and the protocol domain compression PFC negotiation can be used in the prior art to reduce the frame header to 4 bytes, but for small
  • the transmission efficiency of GTP-U packets is up to 50%.
  • the formed GTP-U data packet is shown in Figure 2.
  • the transmission overhead includes GTP-U header, UDP, IP, and Ethernet overhead of 58 or 62 bytes.
  • the transmission efficiency is up to 83.62%.
  • a data packet is a small data packet, wherein the effective data size is about 40 bytes except for the transmission overhead, and when the transmission overhead is 58 bytes, the transmission efficiency is up to 40.82. %.
  • the transmission overhead includes the GTP-U header, UDP, IP, etc., and the data packet that is usually transmitted is effective except for the transmission overhead.
  • the data size is similar to the transmission overhead. Therefore, there is a disadvantage in the transmission data that the transmission overhead is large, the bandwidth is wasted, and the transmission efficiency is low.
  • the embodiments of the present invention provide a data transmission method, a communication device, and a communication system, which can reduce transmission overhead, improve transmission efficiency, and solve the defects of high transmission overhead, wasted bandwidth, and low transmission efficiency in the prior art.
  • the data transmission method provided by the embodiment of the present invention includes: encapsulating data into a general packet radio service tunneling protocol (GTP-U) data packet of more than one user plane;
  • GTP-U general packet radio service tunneling protocol
  • IP Internet Protocol
  • GTP-U General Packet Radio Service Tunneling Protocol
  • UDP User Data Protocol
  • GTP-U user-level General Packet Radio Service Tunneling Protocol
  • GTP-U User Data Protocol
  • GTP-U user-level General Packet Radio Service Tunneling Protocol
  • the compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet includes at least the Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and a user-level general packet radio.
  • the compression header including at least a context identifier (CID), wherein the context identifier (CID) and the uncompressed include the same Internet Protocol (IP) header, a user datagram protocol (UDP)
  • IP Internet Protocol
  • UDP user datagram protocol
  • the context identifier (CID) in the user-level General Packet Radio Service Tunneling Protocol (GTP-U) packet of the Header and User Level General Packet Radio Service Tunneling Protocol (GTP-U) header is the same;
  • GTP-U General Packet Radio Service Tunneling Protocol
  • GTP-U General Packet Radio Service Tunneling Protocol
  • the embodiment of the invention further provides a data transmission method, comprising: receiving an uncompressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet and a user-level general packet radio service tunneling protocol formed after compression a (GTP-U) data packet, wherein the compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet includes at least a context identifier (CID), wherein the context identifier (CID) and Uncompressed user-level general packet radio service tunneling protocol containing the same Internet Protocol (IP) header, User Datagram Protocol (UDP) header and user-level General Packet Radio Service Tunneling Protocol (GTP-U) header (GTP-U) The same context identifier (CID) in the data packet;
  • GTP-U General Packet Radio Service Tunneling Protocol
  • UDP User Datagram Protocol
  • GTP-U User-level General Packet Radio Service Tunneling Protocol
  • GTP- user-level general packet radio service tunneling protocol
  • GTP-U user-level General Packet Radio Service Tunneling Protocol
  • U A context identifier (CID) in the data packet, which is used to restore the user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet formed after the compression.
  • An embodiment of the present invention provides a communication device, including: an encapsulating unit, configured to encapsulate data into a general packet radio service tunneling protocol (GTP-U) data packet of more than one user plane;
  • a compression unit configured to: in the encapsulated more than one user-level General Packet Radio Service Tunneling Protocol (GTP-U) packet, in a part of user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet Internet Protocol (IP) header, User Datagram Protocol (UDP) header And the user-level General Packet Radio Service Tunneling Protocol (GTP-U) header compression, forming a compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) packet, the compressed user-level general packet
  • the Wireless Service Tunneling Protocol (GTP-U) packet includes at least the Internet Protocol (IP) header, the User Data Protocol (UDP) header, and the User Layer General Packet Radio Service Tunneling Protocol (GTP-U) header.
  • the compression header including at least a context identifier (CID), the context identifier (CID) being the same as a context identifier (CID) in an uncompressed data packet, for receiving device decompression
  • the sending unit is configured to send an uncompressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet, and send the compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet.
  • GTP-U General Packet Radio Service Tunneling Protocol
  • An embodiment of the present invention provides a receiving apparatus, including:
  • a third receiving unit configured to receive, by the sending device, an uncompressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet and a compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) data packet.
  • the compressed user plane General Packet Radio Service Tunneling Protocol (GTP-U) data packet includes a context identifier (CID);
  • a decompression unit configured to: according to the received user-level general packet radio service tunneling protocol (GTP-U) data packet formed by compression, a context identifier (CID), and the uncompressed user plane general packet radio A context identification (CID) in the Service Tunneling Protocol (GTP-U) packet, which restores the compressed user-level General Packet Radio Service Tunneling Protocol (GTP-U) packet.
  • GTP-U general packet radio service tunneling protocol
  • CID context identifier
  • CID uncompressed user plane general packet radio A context identification
  • GTP-U Service Tunneling Protocol
  • the embodiment of the invention provides a communication system, including:
  • a transmitting device such as the one described above;
  • a receiving device such as the one described above.
  • the transmitting device and the receiving device negotiate the compressed information
  • the transmitting device sends the IP in the GTP-U data packet according to the negotiation result.
  • the header, UDP header, and GTP-U header are combined and compressed, and then the GTP-U number formed by the compressed IP header, UDP header, and GTP-U header sent by the transmitting device is transmitted.
  • the receiving device restores the header of the complete GTP-U data packet according to the negotiated information, thereby saving transmission overhead and improving transmission efficiency.
  • 1 is a GTP-U packet format formed on a PPP link in the prior art
  • FIG. 3 is a flow chart showing a method for transmitting data according to an embodiment of the present invention from a transmitting device
  • FIG. 4 is a flow chart showing a method for transmitting data according to an embodiment of the present invention from a receiving device
  • FIG. 5 is a flowchart of a method for transmitting data according to a first embodiment of the present invention
  • FIG. 6 is a flowchart of a method for transmitting data according to a second embodiment of the present invention.
  • FIG. 8 is a flowchart of a method for encapsulating a complete GTP-U data packet transmitted on a PPP link according to Embodiment 2 of the present invention
  • FIG. 9 is a schematic diagram of the second embodiment of the present invention in which the encapsulation becomes a complete transmission in a routing network environment.
  • FIG. 10 is a schematic diagram of a compression range of a complete GTP-U data packet in Embodiment 2 of the present invention
  • FIG. 11 is a format of an IP header in a complete GTP-U data packet according to Embodiment 2 of the present invention
  • FIG. 13 is a format of the GTP-U header in the complete GTP-U data packet in the second embodiment of the present invention
  • FIG. 14 is an embodiment of the present invention.
  • the format of the GTP-U/IP/UDP header formed by the joint transmission of the network layer IP header, the transport network layer UDP header and the GTP-U header;
  • FIG. 15 is a flowchart of a method for transmitting data according to a third embodiment of the present invention
  • FIG. 16 is a schematic diagram of a compression range of a complete GTP-U data packet according to Embodiment 3 of the present invention
  • a composition diagram of a communication device provided;
  • FIG. 18 is a structural diagram of a communication device according to Embodiment 5 of the present invention.
  • FIG. 19 is a structural diagram of a communication device according to Embodiment 6 of the present invention.
  • FIG. 20 is a structural diagram of a receiving apparatus according to Embodiment 7 of the present invention.
  • Figure 21 is a diagram showing the composition of a communication system according to Embodiment 8 of the present invention. detailed description
  • the embodiment of the present invention provides a data transmission method, a communication device, and a communication system.
  • the transmitting device performs compression processing on the transmitted data, and the receiving device restores the compressed data according to establishing the same index as the receiving device, so that the compressed data is restored. It is not necessary to repeatedly transmit the same data during transmission, thereby saving transmission overhead and improving transmission efficiency.
  • the method includes:
  • Step T1 the data is encapsulated into multiple GTP-U data packets; Step T2, the IP header, the UDP header, and the GTP-U header in some GTP-U data packets in the multiple GTP-U data packets.
  • Compressing, forming a compressed GTP-U data packet where the compressed GTP-U data packet includes at least the compressed header formed by compressing the IP header, the UDP header, and the GTP-U header,
  • the compression header includes at least a context identifier CID, wherein the CID is the same as an uncompressed CID in a GTP-U packet containing the same IP header, UDP header, and GTP-U header; step T3,
  • the uncompressed GTP-U data packet in the plurality of GTP-U data packets and the compressed GTP-U data packet are sent to the receiving device.
  • a data transmission method provided by an embodiment of the present invention is described from the receiving device side. Referring to FIG. 4, the method includes:
  • Step P1 receiving an uncompressed GTP-U data packet and a compressed GTP-U data packet, where the compressed GTP-U data packet includes at least a context identifier CID, where the CID and the uncompressed The same CID in the GTP-U packet containing the same IP header, UDP header, and GTP-U header;
  • Step P2 Restore the compressed GTP-U data packet according to the CID in the GTP-U data packet formed after the compression is received and the CID in the uncompressed GTP-U data packet.
  • Step 1 The sending device encapsulates the data into a complete GTP-U data packet, and sends the one Complete GTP-U data packets;
  • Step 2 The sending device and the receiving device establish the same index for the header in the GTP-U data packet; wherein, the same index established in the sending device and the receiving device in step 2 may be according to the sending device and the receiving device.
  • the index established by the preset same indexing information may also be negotiated by the transmitting device and the receiving device to establish an index.
  • the index may be the context identifier CID in the later embodiment.
  • Step 3 The sending device encapsulates the data into multiple complete GTP-U data packets, and compresses the IP header, the UDP header, and the GTP-U header in the encapsulated multiple complete GTP-U data packets, and compresses the compressed GTP.
  • -U data is sent to the receiving device, where the encapsulated GTP-U data packet contains an index;
  • Step 4 The receiving device restores the compressed GTP-U data packet according to the stored index and the index received in the compressed GTP-U data packet.
  • a method for transmitting data the same index is established by a sending device and a receiving device for a header in a complete GTP-U data packet sent by the transmitting device, and the GTP-U is sent by the transmitting device in a subsequent manner.
  • the data packet does not have to send the complete header, but the compressed header is sent.
  • the receiving device matches the stored index with the index in the received GTP-U packet, and compresses the compressed GTP-U packet. Restore, which saves transmission overhead and improves transmission efficiency.
  • both the transmitting device and the receiving device need to obtain the compressed information, and the result of the obtained compressed information may be the result of negotiating the compressed information.
  • Embodiment 1 A data transmission method, as shown in FIG. 5, includes:
  • Step S1 The sending device negotiates compression information with the receiving device.
  • Step S2 the sending device encapsulates the data into multiple GTP-U data packets
  • Step S3 the sending apparatus sends, according to the negotiation compression information, the GTP-U data packets encapsulated in the plurality of GTP-U data packets to the receiving device in time sequence;
  • Step S4 The sending apparatus compresses the IP header, the UDP header, and the GTP-U header in the GTP-U data of the remaining part of the encapsulated plurality of GTP-U data packets according to the negotiation compression information, and compresses the compressed GTP-U data packets are sent to the receiving device in chronological order;
  • Step S5 The receiving device receives the uncompressed GTP-U data packet and the compressed GTP-U data packet, and decompresses the received compressed GTP according to the negotiated information and the sent uncompressed GTP-U data packet.
  • U packet The sending apparatus compresses the IP header, the UDP header, and the GTP-U header in the GTP-U data of the remaining part of the encapsulated plurality of GTP-U data packets according to the negotiation compression information, and compresses the compressed GTP-U data packets are sent to the receiving device in chronological order;
  • Step S5 The receiving device receives the uncompressed GTP-U data packet and the compressed GTP-U data packet
  • the transmitting device is a wireless access device, and the wireless access device may be a base station or a base station controller.
  • the receiving device may be a base station or a serving gateway SGW or the like.
  • the transmitting device negotiates the compressed information with the receiving device, and the transmitting device adds the IP header, the UDP header, and the GTP in the GTP-U packet according to the negotiated compressed information.
  • -U header compression which saves transmission overhead and improves transmission efficiency. This method is generally applicable when the network is busy and the bandwidth is relatively insufficient.
  • the method for transmitting data according to the first embodiment is a general method flow, which can be used for point-to-point networking (such as microwave networking) and routing networking (such as Ethernet transmission), according to different networking scenarios.
  • point-to-point networking such as microwave networking
  • routing networking such as Ethernet transmission
  • Embodiment 2 A data transmission method, which is applicable to a PPP link.
  • the compressed GRP-U packets that meet the PPP link requirements are transmitted on the PPP link.
  • the transmitting device is a base station, and the receiving device transmits data to the base station to which the destination terminal belongs.
  • the receiving device can also be the Serving Gateway SGW. See the method flow chart shown in Figure 6, including:
  • Step Q1 The sending base station and the receiving base station negotiate the compression information by using a network control protocol (NCP protocol), where the NCP protocol is carried on the PPP protocol;
  • NCP protocol network control protocol
  • the specific steps negotiated in step Q1 include: sending a base station to send a negotiation compressed message; receiving the base station receiving the negotiation compressed message, determining whether the compressed data packet can be restored according to its own capability; and transmitting the result of the determination to the transmitting base station.
  • the above is a description of a negotiation process. In fact, there are other methods of negotiation. For reference, refer to the prior art negotiation method, which is not specifically limited herein.
  • the parameters included in the negotiation information sent by the sending base station include: the CID space size TCP_SPACE of the TCP header, the CID space size NON_TCP_SPACE of the non-TCP header, and the maximum between two complete header transmissions.
  • the number of compressed headers sent F_MAX_PERIOD, the maximum duration F_MAX_TIME between two complete header transmissions, the maximum compressible header length MAX_HEADER, the length Length, the type Type, and the IP compression protocol IP-Compression-Protocol combination.
  • the Type Type identifies the length of the negotiation message and the type of the negotiation message.
  • the value of the IP compression protocol IP-Compression-Protocol in this embodiment is usually 16 bits, which is a GTP-compressed character.
  • Table 1 the values of the parameters used in the present embodiment are exemplified in Table 1.
  • Table 7 The format of the negotiation information sent by the transmitting base station is shown in Figure 7.
  • the message format includes the parameters in the negotiation information in Table 1.
  • the receiving base station receives the negotiation compression information sent by the sending base station, and determines that it has the capability to restore the compressed GRP-U data packet after receiving the compressed GTP-U data packet. Therefore, the receiving base station sends a response negotiation compression. Information to the transmitting base station.
  • the transmitting base station receives the response negotiation compression information, and completes the step of negotiating the compression information with the receiving base station.
  • the method of negotiating compressed information can be different.
  • a word is a description of one of the negotiated compression information.
  • Step Q2 The transmitting base station encapsulates the data into multiple GTP-U data packets that are transmitted on the PPP link.
  • the process of specifically encapsulating the data into the GTP-U data packet transmitted on the PPP link in step Q2 may cause different encapsulation processes because the transmitting base station performs different services.
  • the embodiments of the present invention are mainly directed to two types of services, namely, ordinary data services and VoIP services.
  • Step A1 The sending base station receives the data packet that is sent by the terminal, including the data information generated by the terminal, the IP information of the terminal, and the UDP information of the terminal;
  • Step A2 The transmitting base station reassembles the received data information, IP information, and UDP information to form a user plane PDU;
  • Step A3 The sending base station encapsulates the formed user plane PDU according to the GTP-U protocol to form a T-PDU; Step A4, the transmitting base station adds a GTP-U header in front of the T-PDU to form a G-PDU;
  • Step A5 adding a UDP header and an IP header to the G-PDU data by using a path protocol, adding
  • the GTP-U header, the context identifier CID corresponding to the context of the transport network layer IP header and the transport network layer UDP header, is used to form a GPT-U data packet, and the GTP-U data is formed.
  • the composition of the package can still be seen in Figure 1.
  • the IP header includes a context identifier CID corresponding to a context consisting of a complete transport network layer UDP header, a transport network layer IP header, and a GTP-U header, and the same transport network layer UDP header and transmission.
  • the context consisting of the network layer IP header and the GTP-U header is the same, and its CID is the same 16-bit number. It is also possible to encapsulate the CID in the header of the transport network layer UDP.
  • the above description is directed to the process of forming a GTP-U data packet for a normal data service.
  • the formation process of the GTP-U data packet in the VoIP service is similar to the formation process of the GTP-U data packet in the ordinary data service, see the figure. 9, the method includes the step B1 to the step B5, the difference is that in the voice service, the requirement for real-time performance is very high, so the voice frame generated in the terminal needs to be based on RTP (Real-Time Transport Protocol). Package.
  • the RTP-encapsulated data in the terminal can be regarded as the data information in the common data service, and the encapsulated data is similar to the operations in steps A3, A4, and A5, and finally the GTP on the VoIP service is formed.
  • -U packet In fact, in step Q2, a method of encapsulating data into a GTP-U packet in a general data service and a VoIP service is a prior art.
  • Step Q3 The transmitting base station sends, according to the result of the negotiation, the first, the 102nd, the 203th, etc. of the plurality of GTP-U data packets after the encapsulation, and the GTP-U data packets with an interval of 100.
  • the receiving base station; the first, 102th, and 203th GTP-U data packets are defined for the GTP-U data packet according to the time sequence of transmitting the GTP-U data packet.
  • the transmitting base station transmits a complete GTP-U data packet according to the result of the negotiation, that is, when transmitting the first data packet, and transmits the complete GTP when transmitting the 102th data packet.
  • Step Q4 The transmitting base station compresses, according to the negotiated compressed information parameter IP compression protocol, the GTP-U, the second to the 101st, and the 103th to the 202th GTP-U of the plurality of GTP-U data packets.
  • the IP header, UDP header, and GTP-U header of the packet are compressed.
  • the IP header and UDP header are the IP header and UDP header of the transport network layer, and the GTP-U data formed after compression.
  • the packets are sent to the receiving base station in chronological order.
  • the compressed GTP-U packet contains CID information.
  • the transmitting base station continuously transmits 100 compressed GTP-U data packets, then transmits the uncompressed complete GTP-U data packet, and continuously transmits 100 compressed GTP-U data packets, and so on.
  • the length of the CID contained in the GTP-U packet sent is 16 bits
  • the maximum length between two complete header transmissions is 5 seconds
  • the maximum compressible header length is 60 bytes.
  • the transport network layer IP header and the transport network layer in the uncompressed GTP-U data packet transmitted on the PPP link are shown in FIG.
  • the UDP header and the GTP-U header are combined and compressed, and the compressed GTP-U data packet is sent to the receiving base station to save transmission overhead.
  • the transport network layer IP header and the transport network layer UDP header refer to an IP header and a UDP header that are not included in the user plane PDU.
  • the compressed GTP-U data contains the CID.
  • steps Q3 and Q4 when the base station sends the GTP-U data packet to the uncompressed and complete
  • the GTP-U data packet when the process of transmitting the compressed data packet is implemented, may be: a counter is stored in the transmitting base station, and when an uncompressed complete GTP-U data packet is sent, counting starts, and the counting starts. The data packets are sent to the compressed GTP-U data packet. After transmitting 100 compressed GTP-U data packets, the counter is cleared, and the transmitting base station sends an uncompressed complete GTP-U data packet. Analogy.
  • Step Q5 The receiving base station receives the uncompressed complete GTP-U data packet and the compressed GTP-U data packet, and restores the compressed GTP according to the negotiated information and the CID included in the uncompressed complete GTP-U data packet. -U packet.
  • step Q5 after receiving the complete uncompressed GTP-U data packet, the receiving base station establishes a direct contextual correspondence between the CID and the CID in the uncompressed GTP-U data packet, where the context includes transmission.
  • Network layer IP header, transport network layer UDP header and GTP-U header The receiving base station compares the CID in the received compressed GTP-U data packet with the CID in the uncompressed GTP-U data packet. If the CID is the same, the receiving base station can determine that the compressed GTP-U data packet is not present.
  • the context before compression is the same as the context in the received complete GTP-U packet, thus restoring the complete GTP-U packet.
  • the uncompressed GTP-U data packets sent by the transmitting base station Due to the uncompressed GTP-U data packets sent by the transmitting base station, many of the information that must be carried in order to meet the protocol requirements are repeated, and it is meaningless information for the transmitting base station and the receiving base station that have established the connection, in order to reduce this The necessary information occupies the bandwidth, and the compressed GTP-U data packet can be sent in the middle of transmitting the complete uncompressed GTP-U data packet, thereby providing transmission efficiency and reducing transmission overhead.
  • the number of compressed GTP-U data packets sent between two complete uncompressed GTP-U data packets may be negotiated between the transmitting base station and the receiving base station. The result of the negotiation in this embodiment is to transmit 100 compressed GTP-U packets between two complete GTP-U packets to the receiving base station.
  • Inferable amount INFERRED can be derived from existing information.
  • the network layer IP header is transmitted in the GTP-U packet without compression.
  • the IP header is defined by IPv4.
  • the parameters included in the IP header are: version, header length, service type, total length, identity, and identifier. , slice offset, lifetime, protocol, header checksum, original IP address, and destination IP address. See Table 3 for a detailed description of each parameter, and the format of each parameter contained in the IP layer header of the transport network layer in the GTP-U packet is shown in Figure 11.
  • the transmission network layer of the GTP-U packet is different in the IP header except for the flag parameters, and other parameters are the same or can be inferred.
  • the network layer UDP header is transmitted in the GTP-U packet without compression before including parameters: source port number, destination port number, length, and UDP checksum. See Table 4 for the case of the values of the parameters in the UDP complete header. Referring to FIG. 12, it is a format of a UDP complete header, where the source port number, the destination port number, the length, and the UDP checksum length are respectively 16 bits. Between the transmitting base station and the receiving base station that have established the connection, the transmission network layer UDP header of each transmitted GTP-U data packet has a checksum different, Its parameters are the same or can be inferred.
  • the GTP-U complete header in the GTP-U packet without compression see Figure 13 for the GTP-U full header format, including parameters: version, PT, ⁇ flag, S flag, ⁇ flag, message type, length Domain, tunnel endpoint ID, serial number, N-PDU, and next extension header type. See Table 5 for a description of each parameter.
  • the ⁇ identifier is used to indicate whether there is an extended header field
  • the S identifier is used to indicate whether a sequence number exists
  • the ⁇ identifier is used to indicate whether an N-PDU number exists
  • the version field is used to identify a version of the GTP protocol
  • the ⁇ identifier is used to distinguish the protocol.
  • the different parameters are the same or can be inferred when the connection ID of the connection has been established.
  • GTP-U complete header parameter table Between the transmitting base station and the receiving base station that have established the connection, each time a GTP-U data packet is sent, the transport network layer IP header, the transport network layer UDP header, and the GTP-U header described above are all sent. Once again, in fact, in most cases, the same transport network layer IP header, transport network layer UDP header, and GTP-U header are repeatedly transmitted, occupying the transmission bandwidth, making the transmission overhead large and the transmission efficiency low.
  • step Q3 of the second embodiment the parameters of the complete transport network layer IP header, the transport network layer UDP header, and the GTP-U header are unchanged in each GTP-U packet transmitted.
  • the parameter compression that can be inferred, the compressed GTP-U data packet consists of an uncompressed part and a compressed part.
  • the transport network layer IP header, the transport network layer UDP header, and the GTP-U header jointly compressed header format, as shown in FIG.
  • the 16-bit CID is shown in Figure 14 as two rows, the first row is the upper 8 bits of the 16-bit CID, and the second row is the lower 8 bits of the 16-bit CID, which together form a 16-bit context identifier.
  • the context identifier is the same as the identifier included in the complete uncompressed GTP-U data packet sent in step Q3. According to the context identifier, when the receiving base station decompresses, the received complete identifier is compared according to the context identifier. The CID of the GTP-U packet is restored by the context, and the context is composed of a transport network layer IP header, a transport network layer UDP header, and a GTP-U header.
  • the third line includes a parameter T indicating the tunnel endpoint identifier, a parameter I indicating the IPv4 identifier, and a packet sequence generation information, which occupy a total of 1 byte.
  • the parameter T indicating the tunnel endpoint identifier and the parameter I indicating the IPv4 identifier are easily understood below, and will not be described in detail herein.
  • the CID will be bound to a unique Generation. Generation can be understood as the serial number of the transmitted GTP-U packet, and the sequence number of the first GTP-U packet sent is 1, and each subsequent transmission. A total of GTP-U packets are incremented by a serial number.
  • the fourth, fifth, and sixth lines are parameters of the GTP-U packet transmitted in each transmission in the transport network layer UDP header, GTP-U header, and transport network layer IP header, respectively: UDP check And , tunnel endpoint ID and IPv4 identifier.
  • the UDP checksum is usually optional and takes up 2 bytes. When T is 1, it indicates that the tunnel endpoint identifier of the GTP-U header is different from the tunnel endpoint identifier in the complete GTP-U header sent before uncompressed. Therefore, the GTP-U header needs to retain 4 words.
  • the tunnel endpoint identifier of the section if T is 0, the tunnel endpoint identifier of the GTP-U header is the same as the tunnel endpoint identifier in the complete GTP-U header sent before uncompressed, so the compressed header may not contain This parameter.
  • Reference The number I is similar to the role of T. The difference is that when I is 1, the IPv4 identifier of the IP header is different from the IPv4 identifier in the complete IP header before being compressed. Therefore, the IP header needs to be reserved for 2 times.
  • the IPv4 identifier of the byte in the same way, can be inferred that when I is 0, the compressed header may not contain this parameter.
  • the IP header, the UDP header, and the GTP-U header are jointly compressed, and the total number of bytes occupied by this portion is 5, 7, 9, or 11.
  • the GTP-U/UDP/IP header formed after compression is 5 bytes; when T is 1, I is 0, and the compressed GTP-U/UDP/IP is formed.
  • the header is 9 bytes; when T is 0, I is 1 is, the GTP-U/UDP/IP header formed after compression is 7 bytes; when T is 1, I is 1 is, it is formed after compression
  • the GTP-U/UDP/IP header is 11 words T.
  • the above is a description of the compressed format of the IP header, the UDP header, and the GTP-U header, and the uncompressed portion of the GTP-U packet retains the original format, and the portion formed by the compressed portion is compressed.
  • the compressed portions together form a compressed GTP-U packet.
  • the compressed format retains the variables that are changed each time a GTP-U packet is sent. , such as: UDP checksum, tunnel endpoint identifier and IPv4 identifier, each time the amount of constant or speculative amount is replaced by a single code, such as: CID, when sending a complete GTP-U packet,
  • the package code is included to know the complete information represented by the package code.
  • the transmitting base station when data is output on a PPP link, the transmitting base station negotiates compression information with the receiving base station, and the transmitting base station performs GTP-U according to the compressed information after negotiation.
  • the IP header, UDP header and GTP-U header compression in the transport network layer are transmitted in the data packet, thereby saving transmission overhead and improving transmission efficiency.
  • a method for transmitting data according to the second embodiment of the present invention is applicable to data transmission on a PPP link.
  • a data transmission method provided in Embodiment 3 of the present invention is applicable to transmission requirements on an Ethernet. The following is a description of the third embodiment of the present invention.
  • the third embodiment is a data transmission method, and the method is applicable to an Ethernet network, that is, a routing network.
  • the sending device may be a base station
  • the receiving device may be a base station or a core network side device, that is, the sending device and the receiving device are devices at both ends of the GTP tunnel.
  • the transmitting device is a transmitting base station
  • the receiving device is a receiving base station. Referring to FIG. 15, the specific steps include: In step F1, the transmitting base station negotiates compression information with the receiving base station.
  • the step F1 is similar to the step Q1 in the second embodiment of the present invention.
  • the parameters of the step F1 and the step Q1 are the same: the parameters negotiated by the sending base station and the receiving base station in the process of negotiating the compressed information may be similar, and the negotiated parameters may include: TCP header CID space size TCP_SPACE, non-TCP header CID space size NON_TCP_SPACE, maximum number of compression headers that can be sent between two complete header transmissions F_MAX_PERIOD, maximum duration between two complete header transmissions F_MAX_TIME, maximum compressible header A combination of any one or more of the length MAX_HEADER, length Length, type Type, and IP compression protocol IP-Compression-Protocol.
  • the negotiation result in the second embodiment can be referred to, that is, the result of the negotiation in Table 1.
  • step F1 the protocol specification used in the process of negotiating the compressed information is not unified in the industry, but is implemented according to the existing technical knowledge.
  • the purpose of the transmission base station to negotiate compressed information with the receiving base station is easy to implement. It is not specifically limited herein.
  • Step F2 The transmitting base station encapsulates the data into a plurality of GTP-U data packets that are transmitted on the Ethernet, where the transport network layer IP header in the GTP-U data packet includes a context identifier.
  • the context identifier described in step F2 is the CID of the context composed of the radio network layer IP header, the radio network layer UDP header, and the GTP-U header.
  • the specific encapsulation process of the step F2 is similar to the step Q2 in the second embodiment of the present invention.
  • the two services are generally used, that is, the ordinary data service and the VoIP service, and the sending base station describes the step Q2.
  • the difference is: First, the third embodiment is directed to the routing network, and the header in the GTP-U packet is a header formed according to the Ethernet related protocol; secondly, the GTP-U packet transmission network layer IP
  • the CID contained in the header is the CID of the context consisting of the wireless network layer IP header, the wireless network layer UDP header, and the GTP-U header.
  • the structure diagram of the GTP-U data packet formed by the transmitting base station can be referred to FIG. 2.
  • the method for encapsulating data into GTP-U data packets in two services is prior art.
  • Step F3 The transmitting base station sends, according to the result of the negotiation, the first, the 102nd, the 203th, etc. of the plurality of GTP-U data packets after the encapsulation, and the GTP-U data packets with an interval of 100.
  • the receiving base station; the first, the 101st, and the 203th GTP-U data packet are sent according to the GTP-U
  • the chronological order of the packets is defined for the GTP-U packet.
  • step F3 is similar to step Q3.
  • Step F4 The transmitting base station compresses, according to the negotiated compressed information parameter IP compression protocol, the GTP-U, the second to the 101st, the 103th to the 202th, and the like GTP-U of the plurality of GTP-U data packets.
  • the IP header, UDP header, and GTP-U header of the packet are compressed.
  • the IP header and UDP header are the IP header and UDP header of the transport network layer, and the GTP-U data formed after compression.
  • the packets are sent to the receiving base station in chronological order.
  • the compressed GTP-U packet contains CID information.
  • the GTP-U header and the wireless network layer IP in the uncompressed GTP-U data packet sent.
  • the header and the UDP header of the wireless network layer are combined and compressed, and the compressed GTP-U data packet is sent to the receiving base station, thereby saving transmission overhead.
  • the IP header and the radio network layer UDP header of the radio network layer refer to the IP header and UDP header included in the user plane PDU.
  • the wireless network layer IP header, the wireless network layer UDP header and the transport network layer IP header, the transport network layer UDP header format and the included parameters are similar, therefore, the transmitting base station will GTP-U head, wireless
  • the compressed format of the network layer IP header and the wireless network layer UDP header is similar to the format in the second embodiment.
  • the compression of the compressed partial compression format in the second embodiment may be performed.
  • the post-formed portion and the uncompressed portion together constitute a compressed GTP-U packet.
  • Step F5 similar to step Q5, the receiving base station receives the uncompressed complete GTP-U data packet and the compressed GTP-U data packet, according to the negotiated information and the CID included in the uncompressed complete GTP-U data packet. Restore compressed GTP-U packets.
  • the transmitting base station negotiates compression information with the receiving base station, and the transmitting base station performs GTP-U data according to the compressed information after negotiation.
  • the IP header in the wireless network layer of the packet, the UDP header and the GTP-U header in the wireless network layer are compressed, thereby saving transmission overhead and improving transmission efficiency.
  • Embodiments 1, 2, and 3 of the present invention are descriptions of the method provided by the embodiment of the present invention.
  • the embodiment of the present invention also provides a transmitting device and a receiving device.
  • Embodiments 4, 5, and 6 are sending according to the embodiment of the present invention. Description of the device.
  • Embodiment 4 A communication device, as shown in FIG. 17, includes: a receiving unit 10, a packaging unit 20, a transmitting unit 30, a negotiating unit 40, and a compressing unit 50, where:
  • the receiving unit 10 is configured to receive the response negotiation compression information sent by the receiving device, and is further configured to receive data sent by the terminal, and the encapsulating unit 20 is configured to encapsulate the data sent by the terminal into an uncompressed complete GTP-U data packet.
  • the IP header of the GTP-U packet includes a context identifier CID; the negotiating unit 40 is configured to negotiate compression information with the receiving device according to the response negotiation compression information received by the receiving unit 10; and the compression unit 50 is configured to use the negotiation unit.
  • the negotiated compression information compresses the IP header, the UDP header, and the GTP-U header in the encapsulated complete GTP-U packet to form a compressed GTP-U packet, and the compressed GTP
  • the -U packet includes at least the CID, and the header formed by the IP header, the UDP header, and the GTP-U header is a GTP-U/UDP/IP header; the sending unit 30 is configured to send
  • the negotiated compressed information generated by the negotiating unit 40 transmits the uncompressed complete GTP-U data packet and transmits the compressed GTP-U data packet.
  • the negotiation unit 40 in the communication device provided by the fourth embodiment of the present invention may also be replaced by the obtaining unit, that is, the device may obtain the compressed information without negotiation, and the compressed information may be in advance in the device.
  • the saved information is obtained by the obtaining unit when needed, and the functions of the device are implemented together.
  • the transmitting device negotiates the compressed information with the receiving device, the sending device performs the GTP-U data according to the compressed information obtained after the negotiation, or the transmitting device according to the compressed information obtained by the acquiring unit.
  • the IP header, UDP header and GTP-U header are compressed in the packet, thereby saving transmission overhead and improving transmission efficiency.
  • the communication device described in the fourth embodiment of the present invention operates in different networks, and the functions of the modules of the communication device may be different.
  • the following describes the communication devices working in different networks according to specific embodiments. .
  • Embodiment 5 A communication device, the device is applicable to a PPP link, and the device may be a base station or a serving gateway SGW.
  • the communication device includes: a first receiving unit 101, a first encapsulating unit 201, a first transmitting unit 301, a first negotiating unit 401, and a first compression unit. 501.
  • the first receiving unit 101 is configured to receive data sent by the terminal, where the data sent by the terminal includes original data generated by the terminal, IP information of the terminal, and UDP information of the terminal, and the first receiving unit 101 sends the data sent by the terminal.
  • the first encapsulating unit 201 encapsulates the data into a GTP-U data packet that is transmitted on the PPP link, where the context identifier CID is encapsulated in the transport network layer IP header in the encapsulation process.
  • the context identifier CID is an identifier of a context consisting of a transport network layer IP header, a transport network layer UDP header, and a GTP-U header.
  • the first loading unit 201 performs an operation of encapsulating the data into a GTP-U packet conforming to the transmission on the PPP link, after the first negotiation unit 401 negotiates the compression information with the receiving device.
  • the first negotiating unit 401 is configured to negotiate compression information with the receiving device, so that the receiving device can restore the data after receiving the compressed GTP-U data packet; when the first negotiation unit 401 negotiates the compression information with the receiving device, the first negotiation unit 401 passes the A receiving unit 101 and a first transmitting unit 301 exchange the negotiated compression information with the receiving device.
  • the first negotiating unit 401 and the receiving device may negotiate compression information through the NCP protocol, and the NCP protocol 7 is carried on the PPP protocol.
  • the first compression unit 501 is configured to jointly compress the first and the transmission network layer UDP header according to the negotiated compression information in the first negotiation unit 401, so that the GTP-U/UDP/IP header formed after compression is 5 , 7, 9, or 11 bytes.
  • the resulting compressed GTP-U packet consists of a compressed GTP-U/UDP/IP header and an uncompressed portion.
  • the compressed GTP-U packet contains the same CID as in the first encapsulation unit 201.
  • the first sending unit 301 is configured to send the complete GTP-U data packet encapsulated by the first encapsulating unit 201 according to the information negotiated in the first negotiating unit 401, and send the GTP-U data compressed by the first compressing unit 501. Packet, the negotiation information negotiated between the transmitting and receiving base stations.
  • the first negotiation unit 401 in the communication device negotiates compression information with the receiving device, and the first compression unit 501 sets the GTP-U data according to the negotiated compression information.
  • the IP header of the transport network layer, the UDP header of the transport network layer, and the GTP-U header are compressed in the packet, thereby saving transmission overhead and improving transmission efficiency.
  • the fifth embodiment provides a communication device on a PPP link.
  • a communication device suitable for an Ethernet network that is, a routing network environment, is specifically provided. See Example 6 for details.
  • Embodiment 6 is a communication device.
  • the device is applicable to an Ethernet network, that is, a routing network environment, and the device may be a base station or a base station controller.
  • the communication device includes: a second receiving unit 102, a second encapsulating unit 202, a second transmitting unit 302, a second negotiating unit 402, and a second compressing unit 502.
  • a communication device provided in Embodiment 6 of the present invention is similar to the device provided in Embodiment 5 of the present invention, except that the device provided in Embodiment 6 of the present invention is applied to a routing networking environment.
  • the format of the GTP-U data packet encapsulated in the second encapsulating unit 202 is in accordance with a format specified by a protocol of the routing network, and is different from the GTP-U transmitted in the PPP link.
  • the format of the data packet, and, in the process of encapsulation, the context identifier CID encapsulated in the transport network layer IP header is the context composed of the wireless network layer IP header, the wireless network layer UDP header, and the GTP-U header.
  • the identifier of the second negotiation unit 401 in the negotiation process is different from the first negotiation unit in the fifth embodiment; the second compression unit 502 is based on the compressed message negotiated in the second negotiation unit 402. And compressing the GTP-U header, the wireless network layer IP header, and the wireless network layer UDP header in the encapsulated GTP-U data packet in the second encapsulating unit 202, and compressing the formed GTP-
  • the U/UDPIP header contains the same CID as the encapsulation unit, and the compressed GTP-U/UDP/P header is 5, 7, 9, or 11 bytes.
  • the resulting compressed GTP-U packet consists of a compressed GTP-U/UDP/IP header and an uncompressed portion.
  • a communication device provided in Embodiment 6 of the present invention is the same as the device provided in Embodiment 5, except that the component unit module of the device provided in Embodiment 6 is similar to the component module of the device provided in Embodiment 5, and may be similar to Refer to the description in Example 5.
  • the second negotiation unit 402 in the communication device negotiates compression information with the receiving device, and the second compression unit 502 sets the GTP-U data according to the negotiated compression information.
  • the IP header of the wireless network layer in the packet, the UDP header of the wireless network layer, and the GTP-U header are jointly compressed, thereby saving transmission overhead and improving transmission efficiency.
  • Embodiment 7 is a receiving device, which may be a part of a base station, or may be a core network access device. Referring to FIG. 20, the third receiving unit 60, the third negotiating unit 70, and the third sending unit 80 are included. And decompression unit 90.
  • the third receiving unit 60 is configured to receive the negotiated compression information sent by the sending device, and the complete uncompressed GTP-U packets and compressed GTP-U packets.
  • the third negotiation unit 70 obtains the negotiation compression information in the third receiving unit 60, and negotiates with the self-capability to generate the response negotiation compression information, and sends the response negotiation compression information to the third sending unit 80, and the third sending unit 80 responds.
  • the negotiation compressed information is sent to the transmitting device.
  • the decompressing unit 90 is configured to receive the received compressed GTP-U data according to the negotiation result in the third negotiating unit 70 and the CID in the IP header in the complete GTP-U packet received by the third receiving unit 60.
  • Packet restoration the specific steps of the restoration are: comparing the CID in the received compressed GTP-U packet with the CID of the received complete GTP-U packet, if the two CIDs are the same, then the compression
  • the compressed portion of the GTP-U packet is the same as the context of the complete GTP-U packet, that is, the context represented by the context identifier in the complete GTP-U packet is used as the result of the compression of the compressed portion of the compressed GTP-U packet.
  • the context in the received GTP-U data packet is composed of a transport network layer IP header, a transport network layer UDP header, and a GTP-U header.
  • the protocol negotiated with the peer end can adopt the NCP protocol; if the device communicates with the opposite end in the environment of the routing network, the context in the received GTP-U data packet refers to the IP network layer IP header, the wireless network The layer UDP header and the GTP-U header are composed.
  • the protocol negotiated with the peer does not have a unified protocol at this stage, but the negotiation process is easy to implement using the prior art.
  • the decompressing unit 90 will receive the received information according to the negotiation result of the third negotiating unit 70 and the information of the complete GTP-U packet CID received by the third receiving unit 60.
  • the compressed GTP-U data packet is decompressed, thereby saving transmission overhead and improving transmission efficiency.
  • first negotiating unit 401, the second negotiating unit 402, and the third negotiating unit 70 in the apparatus provided by the fifth, sixth, and seventh embodiments may be respectively configured by the first obtaining unit, the second acquiring unit, and the third.
  • the acquisition unit replaces, that is, the devices provided in Embodiments 5, 6, and 7 do not need to negotiate, but the compression information preset or saved in the device is used to implement the function of compressing, transmitting, or restoring data of each device. .
  • Embodiment 8 A communication system comprising a transmitting device 11 and a receiving device 12, see FIG.
  • the sending device 11 is configured to negotiate compression information with the receiving device 12, where the compressed information may include: a CID space size TCP_SPACE of the TCP header, and a CID space size of the non-TCP header.
  • NON_TCP_SPACE the maximum number of compression headers that can be sent between two complete header transmissions
  • F_MAX_PERIOD the maximum duration between two complete header transmissions
  • F_MAX_TIME the maximum compressible header length
  • MAX_HEADER maximum compressible header length
  • MAX_HEADER maximum compressible header length
  • type Type type Type
  • the transmitting device 11 and the receiving device 12 communicate on the PPP link, and the context represented by the CID includes a transport network layer IP header, a transport network layer UDP header, and a GTP-U header; if the transmitting device 11 and the receiving device
  • the device 12 communicates in the environment of the routing network, and the context represented by the CID includes a wireless network layer IP header, a wireless network layer UDP header, and a GTP-U header.
  • the transmitting device 11 sends a complete GTP-U data packet to the receiving device 12 according to the negotiation result;
  • the compressed portion is a transport network layer IP header, a transport network layer UDP header, and a GTP-U header, and the compressed format includes a CID; If the transmitting device 11 and the receiving device 12 communicate in the environment of the routing network, the compressed portion includes a wireless network layer IP header, a wireless network layer UDP header, and a GTP-U header, and the compressed format includes the CID.
  • the transmitting device 11 transmits the compressed GTP-U data packet to the receiving device.
  • the receiving device 12 receives the negotiation message with the transmitting device 11, receives the complete GTP-U data packet sent by the transmitting device 11, and the compressed GTP-U data packet, and the receiving device 12 receives the complete GTP-U according to the negotiation result.
  • the packet restores the compressed GTP-U packet.
  • the receiving device 12 compares the CID included in the received compressed GTP-U data packet with the CID in the complete GTP-U data packet, and the two CIDs are the same, and the receiving device 12 determines the compressed GTP-U data.
  • the compressed portion of the packet is identical to the context represented by the CID in the complete GTP-U packet, so the receiving device 12 can restore the compressed GTP-U packet.
  • the transmitting device 11 and the receiving device 12 in the communication system may be a wireless side access device as described in the fifth embodiment and a receiving device provided in the seventh embodiment, or may be a wireless device provided in the fourth embodiment.
  • the transmitting apparatus negotiates the compression information with the receiving apparatus, and the same part of the transmitted GTP-U data packet includes an IP header, a UDP header, and a GTP-U.
  • the header is jointly compressed, and the receiving device restores the compressed according to the negotiated compression information. Reduced data, which saves transmission overhead and provides transmission efficiency.
  • Encapsulating data into a plurality of GTP-U data packets compressing an IP header, a UDP header, and a GTP-U header in a part of the GTP-U data packets of the plurality of GTP-U data packets to form a compressed a GTP-U data packet, where the compressed GTP-U data packet includes at least the compressed header formed by the IP header, the UDP header, and the GTP-U header compressed, and the compressed header includes at least a context.
  • the above-mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

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

Description

一种数据的传输方法、 通信设备及通信***
本申请要求于 2008 年 8 月 22 日提交中国专利局、 申请号为 200810042023.3、 发明名称为 "一种数据的传输方法、 通信设备及通信***" 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及通信技术领域， 尤其涉及一种数据的传输方法、通信设备及通 信***。
背景技术
隧道技术（ Tunneling )是一种通过使用互联网络的基础设施在网络之间传 递数据的方式。使用隧道传递的数据（或负载）可以是不同协议的数据帧或包。 隧道协议将其它协议的数据帧或包重新封装然后通过隧道发送。新的帧头提供 路由信息， 以便通过互联网传递被封装的负载数据。
随着隧道技术的发展，各种业务已经开始根据本业务的特点制定相应的隧 道协议。 GPRS ( General Packet Radio Service, 通用分组无线业务） 中的隧道 协议为 GTP ( GPRS Tunnel Protocol, GPRS隧道协议）。 通过 GPRS隧道协议 可为多种协议的数据分组通过 GPRS骨干网传输提供隧道。 GTP根据所运载 的协议需求，利用 TCP ( Transmission Control Protocol,传输控制协议 )或 UDP ( User Datagram Protocol, 用户数据报协议） 来提供可靠的连接， 比如支持 X.25的分组传输， 和无连接月良务， 比如 IP(Intemet Protocol, 互联网协议）分 组。
当数据采用 UDP/IP路径协议在 IP网上传输时， 无线接入侧设备需要对 接收到终端发送的数据包采用 GTP重新封装， 形成的用户层面的 GPRS隧道 协议（ GTP-U )数据包。 当所述 IP网为 PPP ( Point-to-Point Protocol, 点对点 链路协议）链路时， 则形成的 GTP-U数据包参见图 1。 由图可知， 其传输开 销包括 GTP-U头、 传输网络层 UDP、 传输网络层 IP和 PPP头开销， 共 43或 47个字节。 对于普通数据业务中传输平均报文长度为 286字节时， 其传输效 率为 87.32 % ,此时的传输开销为 43个字节。通常，在 LTE( Long Time Evolution, 长期演进）或 S AE ( System Architecture Evolution , ***架构演进） ***中有 超过 50 %的数据报文是小数据包， 其中， 除了传输开销外有效数据的大小约 为 40个字节， 或者更小， 当传输开销为 43个字节时， 则其传输效率最大为 48.19 %。 为了减少传输开销， 现有技术中可以通过 PPP ( Point to Point Protocol , 点对点协议 )层地址和控制域压缩 ACFC和协议域压缩 PFC协商， 将 ΡΡΡ帧头减少到 4个字节， 但是对于小的 GTP-U数据包的传输效率最大为 50 %。
当所述的 IP网为以太网时，则形成的 GTP-U数据包参见图 2, 由图可知， 其传输开销包括 GTP-U头、 UDP、 IP、 Ethernet开销共 58或 62字节。 对应普 通数据业务中传输平均报文长度为 286个字节时，当传输开销为 58个字节时， 其传输效率最大为 83.62 %。 通常， 在 LTE或 SAE***中数据报文是小数据 包， 其中， 除了传输开销外有效数据的大小约为 40个字节， 当传输开销为 58 个字节时， 则其传输效率最大为 40.82 %。
由以上对 GTP-U数据包的传输效率的计算可知，现有技术中通过 GTP传 输数据时， 传输开销包括 GTP-U头部、 UDP、 IP等， 通常传输的数据包中除 了传输开销外有效的数据大小与传输开销大小相似， 因此，在传输数据中存在 传输开销大， 浪费带宽， 传输效率低的缺点。
发明内容
本发明实施例提供了一种数据的传输方法、通信设备及通信***， 能够减 少传输开销， 提高传输效率， 解决了现有技术中传输开销大， 浪费带宽， 传输 效率低的缺点。
其中， 本发明实施例提供的一种数据的传输方法， 包括： 将数据封装为多于一个用户层面的通用分组无线业务隧道协议（ GTP-U ) 数据包；
将所述多于一个用户层面的通用分组无线业务隧道协议（ GTP-U )数据包 中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网协 议（IP )头部、 用户数据^艮协议（UDP )头部和用户层面的通用分组无线业务 隧道协议（GTP-U )头部压缩， 形成压缩后的用户层面的通用分组无线业务隧 道协议（GTP-U )数据包， 所述压缩后的用户层面的通用分组无线业务隧道协 议（GTP-U )数据包中至少包含所述互联网协议（IP )头部、 用户数据报协议 ( UDP )头部和用户层面的通用分组无线业务隧道协议（GTP-U )头部压缩后 形成的压缩头部， 所述压缩头部至少包括上下文标识（CID), 其中， 所述的 上下文标识（CID) 与未压缩的包含相同的互联网协议（IP) 头部、 用户数据 报协议（UDP)头部和用户层面的通用分组无线业务隧道协议（GTP-U)头部 的用户层面的通用分组无线业务隧道协议（GTP-U)数据包中的上下文标识 (CID)相同；
将所述多于一个用户层面的通用分组无线业务隧道协议（ GTP-U )数据包 中未压缩的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包和所述压 缩后形成的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包发送给接 收装置。
本发明实施例还提供了一种数据的传输方法， 包括： 接收未压缩的用户层面的通用分组无线业务隧道协议（ GTP-U)数据包和 压缩后形成的用户层面的通用分组无线业务隧道协议（GTP-U)数据包， 所述 压缩后形成的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中至少 包括上下文标识（CID), 其中， 所述的上下文标识（CID)与未压缩的包含相 同的互联网协议 (IP)头部、 用户数据报协议（UDP)头部和用户层面的通用 分组无线业务隧道协议（ GTP-U )头部的用户层面的通用分组无线业务隧道协 议（GTP-U)数据包中的上下文标识（CID)相同；
根据所述接收压缩后形成的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中的上下文标识（CID)与所述接收未压缩的用户层面的通 用分组无线业务隧道协议（GTP-U)数据包中的上下文标识（CID), 将所述 压缩后形成的用户层面的通用分组无线业务隧道协议（GTP-U)数据包还原。 本发明实施例提供了一种通信设备， 包括： 封装单元，用于将数据封装为多于一个用户层面的通用分组无线业务隧道 协议（GTP-U)数据包；
压缩单元，用于将所述封装后的多于一个用户层面的通用分组无线业务隧 道协议 （GTP-U) 数据包中部分用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中的互联网协议（IP)头部、 用户数据报协议（UDP)头部 和用户层面的通用分组无线业务隧道协议（GTP-U )头部压缩， 形成压缩后的 用户层面的通用分组无线业务隧道协议（GTP-U )数据包， 所述压缩后的 用 户层面的通用分组无线业务隧道协议（ GTP-U )数据包中至少包含所述互联网 协议（IP )头部、 用户数据^艮协议（UDP )头部和用户层面的通用分组无线业 务隧道协议（ GTP-U )头部压缩后形成的压缩头部， 所述压缩头部至少包含上 下文标识（CID ), 所述上下文标识（CID )与未压缩的数据包中的上下文标识 ( CID )相同， 用于接收装置解压缩所述压缩后的用户层面的通用分组无线业 务隧道协议（GTP-U )数据包；
发送单元， 用于发送未压缩的用户层面的通用分组无线业务隧道协议 ( GTP-U ) 数据包， 发送压缩后的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包。 本发明实施例提供了一种接收装置， 包括：
第三接收单元，用于接收发送装置发送未压缩的用户层面的通用分组无线 业务隧道协议（ GTP-U )数据包和压缩后的用户层面的通用分组无线业务隧道 协议（GTP-U )数据包， 所述为压缩的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中包含上下文标识（CID );
解压缩单元，用于根据所述接收压缩后形成的用户层面的通用分组无线业 务隧道协议（GTP-U )数据包中的上下文标识（CID )与所述接收未压缩的用 户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的上下文标识（ CID ), 将所述压缩后的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包还原。 本发明实施例提供了一种通信***， 包括：
发送装置， 如上述所说的一种通信设备；
接收装置， 如上述所说的一种接收装置。 本发明实施例提供的技术方案，通过发送装置和接收装置协商压缩信息， 发送装置间隔的发送未压缩的完整的 GTP-U数据包后， 发送装置根据协商结 果将 GTP-U数据包中的 IP头部、 UDP头部和 GTP-U头部联合起来压缩， 之 后发送装置发送的压缩 IP头部、 UDP头部和 GTP-U头部后形成的 GTP-U数 据包到接收装置， 接收装置根据协商的信息， 还原出完整的 GTP-U数据包的 头部， 从而节省了传输开销， 提高了传输效率。 附图说明
图 1是现有技术中在 PPP链路上形成的 GTP-U数据包格式；
图 2是现有技术中在路由组网环境中形成的 GTP-U数据包格式；
图 3是从发送装置说明本发明实施例提供的一种数据的传输方法的方法流 程图；
图 4是从接收装置说明本发明实施例提供的一种数据的传输方法的方法流 程图；
图 5是本发明实施例一提供的一种数据的传输方法的方法流程图； 图 6是本发明实施例二提供的一种数据的传输方法的方法流程图； 图 7是本发明实施例二中协商压缩信息的消息格式；
图 8是本发明实施例二中封装成为完整的符合 PPP链路上传输的 GTP-U数 据包的方法流程图；
图 9是本发明实施例二中封装成为完整的符合路由组网环境中传输的
GTP-U数据包的方法流程图；
图 10是本发明实施例二中对完整的 GTP-U数据包的压缩范围示意图； 图 11是本发明实施例二中完整的 GTP-U数据包中 IP头部的格式； 图 12是本发明实施例二中完整的 GTP-U数据包中 UDP头部的格式； 图 13是本发明实施例二中完整的 GTP-U数据包中 GTP-U头部的格式； 图 14是本发明实施例二中将传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U头部联合压缩后的形成的 GTP-U/IP/UDP头部的格式；
图 15是本发明实施例三提供的一种数据的传输方法的方法流程图； 图 16是本发明实施例三中对完整的 GTP-U数据包的压缩范围示意图； 图 17是本发明实施例四提供的一种通信设备的组成图；
图 18是本发明实施例五提供的一种通信设备的组成图；
图 19是本发明实施例六提供的一种通信设备的组成图；
图 20是本发明实施例七提供的一种接收装置的组成图；
图 21是本发明实施例八提供的一种通信***的组成图。 具体实施方式
本发明实施例提供了一种数据的传输方法、通信设备及通信***，通过发 送装置将发送的数据做压缩处理， 接收装置根据与接收装置中建立相同的索 引， 将压缩后的数据还原， 使得在传输过程中不必重复的传输相同的数据， 从 而节省了传输开销， 提高了传输效率。
首先，从发送装置一侧说明本发明实施例提供的一种数据的传输方法， 参 见图 3所示， 包括：
步骤 T1 , 将数据封装为多个 GTP-U数据包； 步骤 T2, 将所述多个 GTP-U数据包中部分 GTP-U数据包中的 IP头部、 UDP头部和 GTP-U头部压缩， 形成压缩后的 GTP-U数据包， 所述压缩后的 GTP-U数据包中至少包含所述 IP头部、 UDP头部和 GTP-U头部压缩后形成 的压缩头部， 所述压缩头部至少包括上下文标识 CID, 其中， 所述的 CID与 未压缩的包含相同的 IP头部、 UDP头部和 GTP-U头部的 GTP-U数据包中的 CID相同； 步骤 T3 , 将所述多个 GTP-U数据包中未压缩的 GTP-U数据包和所述压 缩后形成的 GTP-U数据包发送给接收装置。 其次，从接收装置一侧说明本发明实施例提供的一种数据的传输方法， 参 见图 4, 包括：
步骤 P1 ,接收未压缩的 GTP-U数据包和压缩后形成的 GTP-U数据包， 所述 压缩后形成的 GTP-U数据包中至少包括上下文标识 CID, 其中， 所述的 CID与 未压缩的包含相同的 IP头部、 UDP头部和 GTP-U头部的 GTP-U数据包中的 CID 相同；
步骤 P2,根据所述接收压缩后形成的 GTP-U数据包中的 CID与所述接收 未压缩的 GTP-U数据包中的 CID, 将所述压缩后形成的 GTP-U数据包还原。 以上是分别从发送装置，或接收装置一侧对本发明实施例提供的一种数据 的传输方法做说明。 下面从发送装置和接收装置两侧，对本发明实施例提供的 一种数据的传输方法进行说明， 包括以下步骤：
步骤 1 , 发送装置将数据封装为一个完整的 GTP-U数据包， 发送所述的一 个完整 GTP-U数据包；
步骤 2,发送装置和接收装置为该 GTP-U数据包中的头部建立相同的索引； 其中， 步骤 2中发送装置和接收装置中建立的相同的索引， 可以是根据发 送装置和接收装置中预置的相同的建立索引信息来建立的索引，也可以是由发 送装置和接收装置协商通信， 来建立索引。所述的索引可以是后面实施例中的 上下文标识 CID。
步骤 3, 发送装置将数据封装为多个完整 GTP-U数据包， 将封装后多个完 整 GTP-U数据包中 IP头部、 UDP头部和 GTP-U头部压缩， 将压缩后的 GTP-U数 据发送到接收装置， 其中， 封装后的 GTP-U数据包中包含索引；
步骤 4, 接收装置根据保存的索引和接收到压缩后的 GTP-U数据包中的索 引相符， 将压缩后的 GTP-U数据包还原。
本发明实施例提供的一种数据的传输方法，通过发送装置和接收装置对发 送装置中发送的一个完整的 GTP-U数据包中头部建立相同的索引，发送装置在 后续发送的 GTP-U数据包中不必发送完整的头部， 而是发送压缩后的头部，接 收装置根据保存的索引和接收到压缩后的 GTP-U数据包中的索引相符，将压缩 后的 GTP-U数据包还原， 从而节省了传输开销， 提高了传输效率。 为了使数据传输更准确， 更可靠，通常发送装置和接收装置都需要获取压缩信 息， 所述获取的压缩信息的结果可以是协商压缩信息的结果。 以下的实施例将 会对本发明实施例提供的方法做详细的说明。
下面结合具体实施例和附图对本发明实施例作详细介绍。
实施例一， 一种数据的传输方法， 参见图 5, 包括：
步骤 S1 , 发送装置与接收装置协商压缩信息；
步骤 S2, 所述发送装置将数据封装为多个 GTP-U数据包；
步骤 S3, 所述发送装置根据协商压缩信息，将封装多个 GTP-U数据包中部 分 GTP-U数据包按照时间顺序发送给接收装置；
步骤 S4, 所述发送装置根据协商压缩信息，将封装后多个 GTP-U数据包中 其余部分的 GTP-U数据中的 IP头部、 UDP头部和 GTP-U头部压缩， 将压缩后的 GTP-U数据包按照时间顺序发送到接收装置； 步骤 S5 , 接收装置接收未压缩的 GTP-U数据包和压缩后的 GTP-U数据包， 根据协商的信息和发送的未压缩的 GTP-U数据包， 解压缩收到的压缩后的 GTP-U数据包。
其中，所述的发送装置是无线接入侧设备， 该无线接入侧设备可以是基站 或基站控制器等。 所述的接收装置可以是基站或服务网关 SGW等。
采用本发明实施例一提供的一种数据的传输方法，通过发送装置与接收装 置协商压缩信息，发送装置根据协商后的压缩信息，将 GTP-U数据包中 IP头部、 UDP头部和 GTP-U头部压缩， 从而节省了传输开销， 提高了传输效率。 该方法 通常适用于网络忙， 带宽相对不够用的情况下使用。
以上实施例一提供的一种数据的传输方法是一种概括的方法流程，该方法 可用于点到点组网 （如微波组网）和路由组网 （如以太传输）， 根据组网场景 不同， 下面结合实施例二、三分别对这两种情况下用户面协议的压缩方法作详 细说明。
实施例二， 一种数据的传输方法， 该方法适用于 PPP链路。 将压缩的满足 PPP链路要求的 GRP-U数据包在 PPP链路上传输。 在本实施例中发送装置为一 基站， 接收装置为发送数据到目的终端所属的基站。 实际上， 接收装置也可以 是服务网关 SGW。 参见图 6所示的方法流程图， 包括：
步骤 Q1 , 发送基站与接收基站通过网络控制协议（NCP协议） 来协商压 缩信息， 所述 NCP协议承载于 PPP协议上；
其中， 在步骤 Q1中协商的具体步骤包括： 发送基站发送协商压缩消息； 接收基站接收协商压缩消息，根据自身能力判断是否可以还原压缩数据包； 将 判断的结果发送给发送基站。 以上是对一种协商过程的描述， 实际上还存在其 它协商方法， 可以参考现有技术中有关协商的做法， 此处不具体限定。
在通过 NCP协议来协商压缩信息的过程中，发送基站发送的协商信息中包 括的参数包括： TCP头的 CID空间大小 TCP_SPACE、 非 TCP头的 CID空间大小 NON_TCP_SPACE、 两次完整头发送之间最多可发送的压缩头数目 F_MAX_PERIOD、 两次完整头发送之间最大的时长 F_MAX_TIME、 最大可压 缩的头长度 MAX_HEADER、 长度 Length、 类型 Type和 IP压缩协议 IP-Compression-Protocol中的任意一项或者几项的组合。 其中， 长度 Length, 类 型 Type分别标识协商消息的长度和协商消息的类型， IP压缩协议 IP-Compression-Protocol在本实施例的取值为通常为 16位的代表是 GTP压缩的 字符。
参见表 1 , 表 1中例举出本实施例中所用到的各参数的取值； 发送基站发 送的协商信息的格式参见图 7 , 在消息格式中包含了表 1中协商信息中的参数。
Figure imgf000011_0001
表 1.协商压缩信息用参数配置表
接收基站接收到发送基站发送的协商压缩信息，判断出自身有能力可以在 收到压缩后的 GTP-U数据包后， 将压缩后的 GRP-U数据包还原， 因此， 接收基 站发送应答协商压缩信息到发送基站。发送基站接收到应答协商压缩信息， 完 成与接收基站的协商压缩信息步骤。协商压缩信息的方法可以有不同， 以上文 字是对其中一种协商压缩信息的说明。
步骤 Q2,发送基站将数据封装为符合在 PPP链路上传输的多个 GTP-U数据 包。
其中， 步骤 Q2具体将数据封装为符合在 PPP链路上传输的 GTP-U数据包的 过程会因为所述发送基站进行不同业务，导致封装过程有不同。在本发明实施 例主要针对两种业务， 即普通数据业务和 VoIP业务。
当发送基站是针对普通数据业务将数据封装成为 GTP-U数据包的过程，参 见图 8, 包括：
步骤 A1 ,发送基站接收到终端发送的包含终端产生的数据信息、终端的 IP 信息和终端的 UDP信息一起的数据包；
步骤 A2,发送基站将接收到的数据信息、 IP信息和 UDP信息重组形成用户 面 PDU;
步骤 A3, 发送基站将形成的用户面 PDU按照 GTP-U协议封装形成 T-PDU; 步骤 A4,、 发送基站在 T-PDU前面添加了 GTP-U头部， 形成 G-PDU;
步骤 A5 , 通过路径协议在 G-PDU数据中添加 UDP头部和 IP头部， 添加由
GTP-U头部，传输网络层 IP头部和传输网络层 UDP头部组成的上下文所对应的 上下文标识 CID到 IP头部信息中， 最终形成 GPT-U数据包， 所述的 GTP-U数据 包的组成图可以仍然参见图 1。
其中， 所述 IP头部中包含有完整传输网络层 UDP头部、 传输网络层 IP头部 和 GTP-U头部组成的上下文所对应的上下文标识 CID, 相同的传输网络层 UDP 头部、 传输网络层 IP头部和 GTP-U头部所组成的上下文是相同的， 其 CID是同 一个 16位的数字。 也可以将 CID封装在传输网络层 UDP的头部内。
以上的描述是针对普通数据业务时， 形成 GTP-U数据包的过程， 在 VoIP 业务中 GTP-U数据包的形成过程与普通数据业务中 GTP-U数据包的形成过程 是相似的， 参见图 9, 包括步骤 B1至步骤 B5, 区别在于， 在语音业务中， 对实 时性的要求是很高的， 所以在终端产生的语音帧、 还需要根据 RTP ( Real-Time Transport Protocol, 实时传输协议）进行封装。 为了便于理解， 可以将终端中 通过 RTP封装后的数据看成普通数据业务中的数据信息， 再对封装后的数据进 行与步骤 A3、 A4、 A5对应相似的操作， 最终形成 VoIP业务上的 GTP-U数据包。 实际上，步骤 Q2中，在普通数据业务和 VoIP业务中将数据封装成为 GTP-U 数据包的方法是现有技术。
步骤 Q3, 发送基站根据协商后的结果， 将封装后多个 GTP-U数据包中第 1 个、 第 102个、 第 203个等， 以此类推， 间隔为 100个的 GTP-U数据包发送给接 收基站； 所述的第 1个、 第 102个、 第 203个 GTP-U数据包， 是根据发送 GTP-U 数据包的时间顺序对 GTP-U数据包限定的。
其中，在步骤 Q3中发送基站根据协商后的结果，即在发送第 1个数据包时， 是发送完整的 GTP-U数据包，在发送第 102个数据包时，是发送的完整的 GTP-U 数据包， 每次发送完整的 GTP-U数据包的间隔是 100个数据包。
步骤 Q4, 发送基站根据协商的压缩信息参数 IP压缩协议的取值位 GTP压 缩， 将所述多个 GTP-U数据包中第 2个到第 101个， 第 103到第 202个等 GTP-U数 据包的 IP头部、 UDP头部和 GTP-U头部压缩， 所述的 IP头部、 UDP头部是传输 网络层的 IP头部和 UDP头部，将压缩后形成的 GTP-U数据包根据时间顺序发送 给接收基站。 其中， 压缩后的 GTP-U数据包中包含有 CID信息。
发送基站连续发送压缩后的 GTP-U数据包 100个， 然后发送未压缩的完整 的 GTP-U数据包， 再次连续的发送压缩后的 GTP-U数据包 100个， 以此类推。 发送的 GTP-U数据包中包含的 CID的长度为 16位， 两次完整头发送之间最大的 时长为 5秒， 最大可压缩的头长度是 60个字节。
为了清楚的理解步骤 Q3中对 GTP-U数据包的压缩范围， 参见图 10所示， 在 PPP链路上发送的未压缩的 GTP-U数据包中的传输网络层 IP头部、 传输网络 层 UDP头部和 GTP-U头部， 三者联合起来压缩， 再将压缩后形成的 GTP-U数据 包发送到接收基站， 节约传输开销。 所述的传输网络层 IP头部和传输网络层 UDP头部是指不包含在用户面 PDU中的 IP头部和 UDP头部。压缩后的 GTP-U数 据包含有 CID。 在后面的文字中有对压缩前后的头部格式做详细说明。
其中， 步骤 Q3、 Q4中发送基站对 GTP-U数据包何时该发送未压缩完整的
GTP-U数据包， 何时该发送压缩的数据包的实现过程是可以是： 在发送基站中 保存有计数器， 当发送一未压缩完整的 GTP-U数据包后开始计数， 并且， 开始 计数的数据包都发送压缩后的 GTP-U数据包， 当发送 100个压缩后的 GTP-U数 据包后， 计数器清零， 发送基站再发送一个未压缩完整的 GTP-U数据包， 依此 类推。
步骤 Q5、 接收基站接收未压缩的完整的 GTP-U数据包和压缩后的 GTP-U 数据包， 根据协商的信息和未压缩的完整的 GTP-U数据包中包含的 CID, 还原 压缩的 GTP-U数据包。
在步骤 Q5中， 接收基站接收到完整的未压缩的 GTP-U数据包后， 会建立 未压缩 GTP-U数据包中 CID与 CID所代表的完整的上下文直接的对应关系， 所 述上下文包括传输网络层 IP头部， 传输网络层 UDP头部和 GTP-U头部。 接收基 站对比接收的压缩后的 GTP-U数据包中的 CID与发送未压缩的 GTP-U数据包中 的 CID, 如果 CID相同， 则接收基站可以判断出压缩后的 GTP-U数据包在没有 压缩前的上下文与接收到的完整的 GTP-U数据包中的上下文相同， 因此， 还原 出完整的 GTP-U数据包。
由于发送基站发送的未压缩的 GTP-U数据包中，很多为了满足协议要求而 必须携带的信息是重复的，对于已经建立连接的发送基站和接收基站是没有意 义的信息， 为了减少这种不必要的信息占用带宽， 可以采用在发送完整的未压 缩的 GTP-U数据包中间发送压缩的 GTP-U数据包， 从而可以提供传输效率， 减 少传输开销。 其中， 在两次完整的未压缩的 GTP-U数据包中间发送的压缩后的 GTP-U数据包的个数可以是有发送基站与接收基站协商的。在本实施例中的协 商结果是发送两个完整的 GTP-U数据包之间发送 100个压缩后的 GTP-U数据包 到接收基站。
还需要理解的是，全文所举例的数字只是便于理解技术方案的举例， 不应 该理解为该技术方案的限定。
为了更好的理解本发明实施例，下面对没有压缩前的一个完整的 GTP-U数 据包中的传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U头部作说明。 在对 各头部说明之前， 请参照表 2, 了解四个名称解释。 不变量 NOCHANGE 本域不允许任何改变， 若改变将重新发送 全头
变化量 DELTA 本域常发生变化， 但变化通常较小， 只填 写变化的差值 随机变量 RANDOM 本域经常无规律发生变化
可推断量 INFERRED 本域从已有信息可以推算得到
表 2.名称解释
在没有压缩前的 GTP-U数据包中传输网络层 IP头部是由 IPv4中定义的 IP头 部， 该 IP头部包括的参数有： 版本、 首部长度、 服务类型、 总长度、 标识、 标 识、 片偏移、 生存时间、 协议、 首部校验和、 原 IP地址和目的 IP地址。 各参数 的具体说明参见表 3, 且传输网络层 IP头部中包含的各参数在 GTP-U数据包中 的格式参见图 11。 在已经建立连接的发送基站与接收基站之间， 每次发送的
GTP-U数据包的传输网络层 IP头部中除了标志参数是不同，其它参数都是相同 的或者是可以推断出来的。
Figure imgf000015_0001
表 3.IPv4完整头部参数表
在没有压缩前的 GTP-U数据包中传输网络层 UDP头部包括参数： 源端口 号、 目的端口号、 长度和 UDP校验和。 参见表 4, 为 UDP完整头部中各参数的 值的情况。参见图 12, 为 UDP完整头部的格式， 其中， 源端口号、 目的端口号、 长度和 UDP校验和长度分别都为 16位。在已经建立连接的发送基站与接收基站 之间，每次发送的 GTP-U数据包的传输网络层 UDP头部中除了校验和不同， 其 它参数都是相同的或者是可以推断出来的。
Figure imgf000016_0001
表 4.UDP完整头部参数表
在没有压缩前的 GTP-U数据包中 GTP-U完整头部，参见图 13为 GTP-U完整 头部格式， 包括参数： 版本、 PT、 Ε标志、 S标志、 ΡΝ标志、 消息类型、 长度 域、 隧道端点标识、 序列号、 N-PDU和下一扩展头类型。 对每个参数的描述参 见表 5。 其中， Ε标识用于指示是否存在扩展头域， S标识用于指示是否存在序 列号， ΡΝ标识用于指示是否存在 N-PDU号， 版本域用于标识 GTP协议的版本， ΡΤ用于区别协议， ΡΤ=1为 GTP协议， PT=0为 GTP，协议。 在已经建立连接的发 点标识不同， 其它参数都是相同的或者是可以推断出来的。
Figure imgf000016_0002
表 5.GTP-U完整头部参数表 在已经建立连接的发送基站与接收基站之间， 每发送一个 GTP-U数据包 时， 都需要将以上说明的传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U头 部全部发送一遍， 实际上， 大多数情况下都重复的发送了相同的传输网络层 IP 头部、传输网络层 UDP头部和 GTP-U头部， 占用了传输带宽，使得传输开销大， 传输效率低。
因此，在实施例二的步骤 Q3中就将完整的传输网络层 IP头部、传输网络层 UDP头部和 GTP-U头部中在每次发送的 GTP-U数据包中不变的参数和可以推 断出来的参数压缩，压缩后的 GTP-U数据包，由未压缩的部分和压缩部分组成。 其中， 传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U头部联合压缩后的头 格式， 参见图 14, 包括 16位的上下文标识 CID ( Context identifier ) 占 2个字节， 该 16位的 CID在图 14中表示成为两行， 第一行是该 16位 CID的高 8位， 第二行是 该 16位 CID的低 8位， 这两行共同组成一个 16位的上下文标识。 其中， 此上下 文标识与步骤 Q3中发送的完整的未压缩的 GTP-U数据包中包含的标识是相 同， 根据此上下文标识， 接收基站在解压缩时， 根据此上下文标识对比接收到 的完整的 GTP-U数据包的 CID, 还原出该上下文， 所述的上下文是由传输网络 层 IP头部， 传输网络层 UDP头部和 GTP-U头部组成的。
第三行包括指示隧道端点标识的参数 T、指示 IPv4标识的参数 I和数据包序 列号 Generation信息， 一共占 1个字节。 指示隧道端点标识的参数 T和指示 IPv4 标识的参数 I在下面讲到会容易理解， 此处先不做详细说明。 对应每一个给定 的上下文标识 CID都会与唯一的 Generation绑定， Generation可以理解为发送的 GTP-U数据包的序列号， 发送第一个 GTP-U数据包的序列号为 1 , 以后每发送 一共 GTP-U数据包就递增一个序列号。
第四、 五、 六行分别是传输网络层 UDP头部、 GTP-U头部和传输网络层 IP 头部中在每次发送的 GTP-U数据包中变化的参数， 依次为： UDP校验和、 隧道 端点标识和 IPv4标识。 其中， UDP校验和通常是可选的， 占用 2个字节。 当 T 为 1时， 说明该 GTP-U头部的隧道端点标识与未压缩前发送的完整 GTP-U头部 中的隧道端点标识不相同， 所以， 该 GTP-U头部需要保留 4个字节的隧道端点 标识； 如果 T为 0, 说明该 GTP-U头部的隧道端点标识与未压缩前发送的完整 GTP-U头部中的隧道端点标识相同， 所以， 压缩后的头可以不包含此参数。 参 数 I与 T的作用相似， 不同在于， 当 I为 1时， 说明该 IP头部的 IPv4标识与未压缩 前发送完整 IP头部中的 IPv4标识不同，所以，该 IP头部需要保留 2个字节的 IPv4 标识， 同理， 可以推断出 I为 0时， 则压缩后的头可以不包含此参数。
因此， 可以推算出， 将 IP头部、 UDP头部和 GTP-U头部联合压缩， 此部分 压缩后一共占用字节数为 5个、 7个、 9个或 11个。 当 T为 0、 I为 0时， 压缩后形 成的 GTP-U/UDP/IP头部为 5个字节； 当 T为 1、 I为 0是， 压缩后形成的 GTP-U/UDP/IP头部为 9个字节； 当 T为 0、 I为 1是，压缩后形成的 GTP-U/UDP/IP 头部为 7个字节； 当 T为 1、 I为 1是， 压缩后形成的 GTP-U/UDP/IP头部为 11个字 T。
以上是对 IP头部、 UDP头部和 GTP-U头部压缩后的格式的说明， 而 GTP-U 数据包中没有压缩的部分仍然保留原来的格式，被压缩部分压缩后形成的部分 和未压缩的部分共同组成压缩后的 GTP-U数据包。
以上从对 IP头部、 UDP头部和 GTP-U头部压缩前和压缩后格式的对比说 明， 可以看出： 压缩后的格式中保留了每次发送 GTP-U数据包时都会改变的变 量， 如： UDP校验和、 隧道端点标识和 IPv4标识， 将每次不变的量或者可以推 测出的量采用筒单代码替换， 如： CID, 通过在发送完整 GTP-U数据包时， 也 包含所述的筒单代码， 来得知所述的筒单代码所代表的完整信息。
通过以上对本发明实施例二提供的一种数据的传输方法的说明， 在 PPP链 路上输出数据时，通过发送基站与接收基站协商压缩信息，发送基站根据协商 后的压缩信息， 将 GTP-U数据包中传输网络层中的 IP头部、 UDP头部和 GTP-U 头部压缩， 从而节省了传输开销， 提高了传输效率。
本发明实施例二提供的一种数据的传输方法适用于在 PPP链路上的数据 传输， 本发明实施例三提供的一种数据的传输方法适用于以太网上传输要求。 下面是对本发明实施例三的说明。
实施例三， 一种数据的传输方法， 该方法适用于以太网络 Ethernet, 即路 由组网的情况。在本发明实施例三中发送装置可以是基站，接收装置可以是基 站，也可以是核心网络侧设备，即发送装置和接收装置是 GTP隧道两端的设备。 为了方便对本发明实施例三提供的一种数据的传输方法的描述，认为发送装置 为发送基站， 接收装置是接收基站， 参见图 15, 具体步骤包括： 步骤 Fl , 发送基站与接收基站协商压缩信息。
所述步骤 F1与本发明实施例二中的步骤 Q1相似， 步骤 F1与步骤 Q1的相同 点是： 发送基站与接收基站在协商压缩信息的过程中协商的参数可以相似，协 商的参数可以包括： TCP头的 CID空间大小 TCP_SPACE、非 TCP头的 CID空间大 小 NON_TCP_SPACE、 两次完整头发送之间最多可发送的压缩头数目 F_MAX_PERIOD、 两次完整头发送之间最大的时长 F_MAX_TIME、 最大可压 缩的头长度 MAX_HEADER、 长度 Length、 类型 Type和 IP压缩协议 IP-Compression-Protocol中任意一项或者几项的组合。 在本发明实施例三中可 以参照实施例二中的协商结果， 即参见表 1中协商的结果。
步骤 F1与步骤 Q1的区别是： 对于本发明实施例三是在路由组网场景下， 对于协商压缩信息的过程中采用的协议规范， 业界还没有统一， 但是， 根据已 有的技术知识， 实现发送基站与接收基站协商压缩信息的目的是容易实现的。 此处不具体限定。
步骤 F2, 发送基站将数据封装为多个符合在以太网上传输的 GTP-U数据 包， 所述 GTP-U数据包中传输网络层 IP头部包含有上下文标识。
在步骤 F2中所述的上下文标识是无线网络层 IP头部、无线网络层 UDP头部 和 GTP-U头部所组成的上下文的 CID。
其中， 步骤 F2的具体封装过程与本发明实施例二中的步骤 Q2相似， 在本 发明实施例三中也主要针对两种业务， 即普通数据业务和 VoIP业务，发送基站 对步骤 Q2的描述， 不同之处在于： 首先， 实施例三针对的是路由组网的情况， 则 GTP-U数据包中的头部是根据 Ethernet相关协议组成的头部； 其次、 GTP-U 数据包传输网络层 IP头部中包含的 CID是由无线网络层 IP头部、 无线网络层 UDP头部和 GTP-U头部所组成的上下文的 CID。 发送基站形成的 GTP-U数据包 的结构图可以参考图 2。 所述的对两种业务中数据封装成为 GTP-U数据包的方 法为现有技术。
步骤 F3 , 发送基站根据协商后的结果， 将封装后多个 GTP-U数据包中第 1 个、 第 102个、 第 203个等， 以此类推， 间隔为 100个的 GTP-U数据包发送给接 收基站； 所述的第 1个、 第 101个、 第 203个 GTP-U数据包， 是根据发送 GTP-U 数据包的时间顺序对 GTP-U数据包限定的。
其中， 步骤 F3与步骤 Q3相似。
步骤 F4, 发送基站根据协商的压缩信息参数 IP压缩协议的取值位 GTP压 缩， 将所述多个 GTP-U数据包中第 2个到第 101个， 第 103到第 202个等 GTP-U数 据包的 IP头部、 UDP头部和 GTP-U头部压缩， 所述的 IP头部、 UDP头部是传输 网络层的 IP头部和 UDP头部，将压缩后形成的 GTP-U数据包根据时间顺序发送 给接收基站。 其中， 压缩后的 GTP-U数据包中包含有 CID信息。
为了清楚的理解步骤 F3中对 GTP-U数据包的压缩范围， 参见图 16,在路由 组网场景下， 发送的未压缩的 GTP-U数据包中的 GTP-U头部、 无线网络层 IP头 部和无线网络层 UDP头部三者联合起来压缩，将压缩后形成的 GTP-U数据包发 送到接收基站， 节约传输开销。 所述无线网络层的 IP头部和无线网络层 UDP头 部指在用户面 PDU中包含的 IP头部和 UDP头部。
其中，由于无线网络层 IP头部、无线网络层 UDP头部与传输网络层 IP头部、 传输网络层 UDP头部格式和包含的参数对应相似， 因此， 发送基站将 GTP-U头 部，无线网络层 IP头部和无线网络层 UDP头部三者联合起来压缩后的格式与实 施例二中的格式相似， 可以参照实施例二中对被压缩部分压缩后的格式的描 述，被压缩部分压缩后形成的部分和未压缩的部分共同组成压缩后的 GTP-U数 据包。
步骤 F5 , 与步骤 Q5相似， 接收基站接收未压缩完整的 GTP-U数据包和压 缩后的 GTP-U数据包，根据协商的信息和未压缩的完整的 GTP-U数据包中包含 的 CID, 还原压缩的 GTP-U数据包。 具体描述可以参考实施例二中步骤 Q5的描 述。
通过以上对本发明实施例三提供的一种数据的传输方法的说明，在路由组 网的情况下，通过发送基站与接收基站协商压缩信息，发送基站根据协商后的 压缩信息， 将 GTP-U数据包中无线网络层中 IP头部、 无线网络层中 UDP头部和 GTP-U头部压缩， 从而节省了传输开销， 提高了传输效率。
以上本发明实施例一、 二、 三是对本发明实施例提供的方法的说明， 本发 明实施例也提供了发送装置和接收装置， 下面实施例四、 五、 六是对本发明实 施例提供的发送装置的描述。 实施例四， 一种通信设备， 参见图 17, 包括： 接收单元 10、 封装单元 20、 发送单元 30、 协商单元 40和压缩单元 50, 其中：
接收单元 10, 用于接收接收装置发送的应答协商压缩信息， 还用于接收 终端发送的数据； 封装单元 20, 用于将所述终端发送的数据封装为未压缩的完整的 GTP-U 数据包， 所述 GTP-U数据包中 IP头部包含上下文标识 CID; 协商单元 40, 用于根据接收单元 10接收到的应答协商压缩信息与接收装 置协商压缩信息； 压缩单元 50, 用于根据协商单元 40协商的压缩信息， 将封装后的完整的 GTP-U数据包中的 IP头部、 UDP头部和 GTP-U头部压缩，形成压缩后的 GTP-U 数据包， 所述压缩后的 GTP-U数据包中至少包含所述 CID, 所述 IP头部、 UDP头部和 GTP-U头部压缩后形成的头部为 GTP-U/UDP/IP头部； 发送单元 30, 用于发送协商单元 40中产生的协商压缩的信息， 发送未压 缩的完整的 GTP-U数据包， 发送压缩后的 GTP-U数据包。 需要理解的是， 本发明实施例四提供的一种通信设备中的协商单元 40也 可以由获取单元取代， 即该装置可以不需要协商来获取压缩信息， 所述的压缩 信息可以是预先在装置中保存的，在需要使用时， 由获取单元得到所述的压缩 信息， 共同来实现该装置的功能。 采用本发明实施例四提供的一种通信设备，通过发送装置与接收装置协商 压缩信息， 发送装置根据协商后的压缩信息， 或者， 发送装置根据获取单元中 获得的压缩信息， 将 GTP-U数据包中 IP头部、 UDP头部和 GTP-U头部压缩， 从 而节省了传输开销， 提高了传输效率。
以上本发明实施例四中描述的一种通信设备， 工作在不同的网络中， 该通 信设备的各模块的功能会有不同，下面结合具体实施例来对工作在不同网络中 的通信设备做说明。
实施例五、 一种通信设备， 该装置适用于 PPP链路中， 该装置可以是一个 基站， 也可以是服务网关 SGW。 参见图 18, 该通信设备包括： 第一接收单元 101、 第一封装单元 201、 第一发送单元 301、 第一协商单元 401和第一压缩单元 501。
第一接收单元 101 , 用于接收终端发送的数据， 所述终端发送的数据包括 终端产生的原始数据、 终端的 IP信息和终端的 UDP信息， 第一接收单元 101将 接收到的终端发送的数据发送给第一封装单元 201 ,第一封装单元 201将该数据 封装成为符合在 PPP链路上传输的 GTP-U数据包， 其中， 在封装的过程中将上 下文标识 CID封装在传输网络层 IP头部中， 所述的上下文标识 CID是由传输网 络层 IP头部、 传输网络层 UDP头部和 GTP-U头部组成的上下文的标识。 第一封 装单元 201执行将该数据封装成为符合在 PPP链路上传输的 GTP-U数据包的操 作， 可以在第一协商单元 401与接收装置协商压缩信息之后。
第一协商单元 401用于与接收装置协商压缩信息， 使接收装置收到压缩后 的 GTP-U数据包后能够还原出数据； 第一协商单元 401在与接收装置协商压缩 信息时，是通过第一接收单元 101和第一发送单元 301与接收装置交换协商压缩 信息的。 其中， 第一协商单元 401与接收装置可以通过 NCP协议协商压缩信息， 所述 NCP协议 7 载与 PPP协议上。
第一压缩单元 501 , 用于根据第一协商单元 401中协商后的压缩信息，将第 和传输网络层 UDP头部联合压缩， 使得压缩后形成的 GTP-U/UDP/IP头部为 5 个、 7个、 9个或 11个字节。 最终形成的压缩后的 GTP-U数据包由压缩后形成的 GTP-U/UDP/IP头部和未压缩的部分组成。 压缩后的 GTP-U数据包中包含与第 一封装单元 201中相同的 CID。
所述第一发送单元 301用于根据第一协商单元 401中协商的信息，发送第一 封装单元 201封装的完整的 GTP-U数据包，发送经过第一压缩单元 501压缩后的 GTP-U数据包， 发送与接收基站之间协商的协商信息。
通过对本发明实施例五提供的一种通信设备的描述，通过该通信设备中的 第一协商单元 401与接收装置协商压缩信息，第一压缩单元 501根据协商后的压 缩信息， 将 GTP-U数据包中传输网络层的 IP头部、 传输网络层的 UDP头部和 GTP-U头部压缩， 从而节省了传输开销， 提高了传输效率。
实施例五提供了一种在 PPP链路上的通信设备， 在下面本发明实施例六中 提供了一种适用于以太网络 Ethernet, 即路由组网环境下的通信设备， 具体说 明参见实施例六。
实施例六， 一种通信设备， 该装置适用于以太网络 Ethernet, 即路由组网 环境，该装置可以是基站，也可以是基站控制器。参见图 19,该通信设备包括： 第二接收单元 102、 第二封装单元 202、 第二发送单元 302、 第二协商单元 402 和第二压缩单元 502。
实际上本发明实施例六中提供的一种通信设备与本发明实施例五中提供 的装置是相似的，所不同的是， 本发明实施例六中提供的装置是应用在路由组 网的环境中， 所述第二封装单元 202中封装形成的 GTP-U数据包的格式是根据 路由组网的协议所规定的格式， 不同与实施例五中形成的， 在 PPP链路传输的 GTP-U数据包的格式， 而且， 在封装的过程中将传输网络层 IP头部中封装的上 下文标识 CID,是由无线网络层 IP头部、无线网络层 UDP头部和 GTP-U头部 组 成的上下文的标识； 所述第二协商单元 401单元中在协商过程中采用的协议不 同与实施例五中的第一协商单元；所述第二压缩单元 502根据第二协商单元 402 中协商后的压缩消息， 将第二封装单元 202中封装后的 GTP-U数据包中的 GTP-U头部、 无线网络层 IP头部和无线网络层 UDP头部联合压缩， 压缩后形成 的 GTP-U/UDPIP头部包含与封装单元相同的 CID,压缩后形成的 GTP-U/UDP/P 头部为 5个、 7个、 9个或 11个字节。 最终形成的压缩后的 GTP-U数据包由压缩 后形成的 GTP-U/UDP/IP头部和未压缩的部分组成。
本发明实施例六提供的一种通信设备与实施例五提供的装置，除以上描述 的区别，实施例六提供的装置的组成单元模块与实施例五中提供的装置的组成 模块对应相似， 可以参考实施例五中的描述。
通过对本发明实施例六提供的一种通信设备的描述，通过该通信设备中的 第二协商单元 402与接收装置协商压缩信息，第二压缩单元 502根据协商后的压 缩信息， 将 GTP-U数据包中无线网络层的 IP头部、 无线网络层的 UDP头部和 GTP-U头部联合起来压缩， 从而节省了传输开销， 提高了传输效率。
实施例七， 一种接收装置， 该接收装置可以是基站中的一部分， 也可以是 核心网接入设备， 参见图 20, 包括第三接收单元 60、 第三协商单元 70、 第三发 送单元 80和解压缩单元 90。
第三接收单元 60用于接收发送装置发送来的协商压缩信息、完整的未压缩 的 GTP-U数据包和压缩后的 GTP-U数据包。第三协商单元 70获取第三接收单元 60中的协商压缩信息， 与自身能力对比协商， 产生应答协商压缩信息， 将应答 协商压缩信息发送给第三发送单元 80,由第三发送单元 80将应答协商压缩信息 发送给发送装置。解压缩单元 90用于根据第三协商单元 70中的协商结果和第三 接收单元 60接收到的完整的 GTP-U数据包中 IP头部中的 CID, 将接收的压缩后 的 GTP-U数据包还原， 其还原的具体步骤是： 将接收到的压缩后的 GTP-U数据 包中的 CID与接收到的完整的 GTP -U数据包的 CID对比， 如果两个 CID相同， 则该压缩后的 GTP-U数据包中压缩部分与完整的 GTP-U数据包中上下文相同， 即将完整 GTP-U数据包中上下文标识所代表的上下文作为压缩后 GTP-U数据 包中压缩部分的还原结果。 其中， 如果该装置在 PPP链路上与对端通信， 则接 收的 GTP-U数据包中的上下文是指由传输网络层 IP头部、传输网络层 UDP头部 和 GTP-U头部组成， 且与对端协商的协议可以采取 NCP协议； 如果该装置在路 由组网的环境中与对端通信，则接收的 GTP-U数据包中的上下文是指由无线网 络层 IP头部、 无线网络层 UDP头部和 GTP-U头部组成， 与对端协商的协议现阶 段没有统一的协议， 但是协商过程采用现有技术是容易实现。
通过对本发明实施例七提供的一种接收装置的描述，解压缩单元 90根据第 三协商单元 70的协商结果和第三接收单元 60接收的完整 GTP-U数据包 CID的 信息， 将收到的压缩后的 GTP-U数据包解压缩， 从而节省了传输开销， 提高了 传输效率。
需要说明的是， 实施例五、 六、 七分别提供的装置中的第一协商单元 401、 第二协商单元 402、第三协商单元 70可以分别由第一获取单元、第二获取单元、 第三获取单元取代， 即实施例五、 六、 七所提供的装置中不需要进行协商， 而 由装置中预置的、 或保存的压缩信息， 来实现各装置对数据的压缩、 发送或还 原的功能。
以上是对本发明实施例提供的装置的描述，下面对本发明实施例提供的系 统做说明。
实施例八， 一种通信***， 包括发送装置 11和接收装置 12, 参见图 20。 其中，发送装置 11用于与接收装置 12协商压缩信息， 所述的压缩信息可以 包括： TCP头的 CID空间大小 TCP_SPACE、 非 TCP头的 CID空间大小 NON_TCP_SPACE、 两次完整头发送之间最多可发送的压缩头数目 F_MAX_PERIOD、 两次完整头发送之间最大的时长 F_MAX_TIME、 最大可压 缩的头长度 MAX_HEADER、 长度 Length、 类型 Type和 IP压缩协议 IP-Compression-Protocol„ 发送装置 11与接收装置 12协商完成后， 发送装置 11 用于封装符合传输要求的 GTP-U数据包， 其中将 CID封装在 GTP-U数据包中 IP 头部信息中。 其中， 如果发送装置 11与接收装置 12在 PPP链路上通信， 则所述 的 CID所代表的上下文包括传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U 头部； 如果发送装置 11与接收装置 12在路由组网的环境中通信， 则所述 CID所 代表的上下文包括无线网络层 IP头部、 无线网络层 UDP头部和 GTP-U头部。
发送装置 11根据协商结果发送完整的 GTP-U数据包到接收装置 12;发送装
11将封装后的 GTP-U数据包压缩。 其中， 如果发送装置 11与接收装置 12在 PPP 链路上通信， 则压缩的部分为传输网络层 IP头部、 传输网络层 UDP头部和 GTP-U头部， 压缩后的格式中包含 CID; 如果发送装置 11与接收装置 12在路由 组网的环境中通信， 则压缩的部分包括无线网络层 IP头部、 无线网络层 UDP头 部和 GTP-U头部， 压缩后的格式中包含 CID。 发送装置 11将压缩后的 GTP-U数 据包发送给接收装置。
接收装置 12接收与发送装置 11的协商消息，接收发送装置 11发送的完整的 GTP-U数据包和压缩后的 GTP-U数据包，接收装置 12根据协商结果和接收到的 完整的 GTP-U数据包， 将压缩后的 GTP-U数据包还原。 其中， 接收装置 12对比 接收到的压缩后的 GTP-U数据包中包含的 CID与完整的 GTP-U数据包中的 CID, 两个 CID相同， 则接收装置 12判断出该压缩 GTP-U数据包中压缩的部分 与完整的 GTP-U数据包中 CID所代表的上下文相同， 因此， 接收装置 12可以将 压缩的 GTP-U数据包还原。
所述通信***中的发送装置 11和接收装置 12可以是实施例五中说明的一 种无线侧接入装置和实施例七提供的一种接收装置，也可以是实施例四提供的 一种无线侧接入装置和实施例七提供的一种接收装置。
通过以上对本发明实施例八提供的一种通信***的描述，发送装置通过与 接收装置协商压缩信息， 将发送的 GTP-U数据包中相同的部分包括 IP头部、 UDP头部和 GTP-U头部联合压缩，接收装置根据协商的压缩信息， 还原出被压 缩的数据， 从而节省了传输开销， 提供了传输效率。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤 是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可 读存储介质中， 该程序在执行时， 包括如下步骤：
将数据封装为多个 GTP-U数据包； 将所述多个 GTP-U数据包中部分 GTP-U数据包中的 IP头部、 UDP头部 和 GTP-U头部压缩， 形成压缩后的 GTP-U数据包， 所述压缩后的 GTP-U数 据包中至少包含所述 IP头部、 UDP头部和 GTP-U头部压缩后形成的压缩头部， 所述压缩头部至少包括上下文标识 CID, 其中， 所述的 CID与未压缩的包含 相同的 IP头部、 UDP头部和 GTP-U头部的 GTP-U数据包中的 CID相同； 将所述多个 GTP-U数据包中未压缩的 GTP-U数据包和所述压缩后形成 的 GTP-U数据包发送给接收装置。 上述提到的存储介质可以是只读存储器， 磁盘或光盘等。
以上对本发明实施例所提供的一种数据的传输方法、通信设备及通信*** 述， 以上实施例的说明只是用于帮助理解本发明的方法及其核心思想； 同时， 对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围 上均会有改变之处， 综上所述， 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 一种数据的传输方法， 其特征在于， 包括：
将数据封装为多于一个用户层面的通用分组无线业务隧道协议（ GTP-U ) 数据包；
将所述多于一个用户层面的通用分组无线业务隧道协议（ GTP-U)数据包 中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网协 议（IP)头部、 用户数据^艮协议（UDP)头部和用户层面的通用分组无线业务 隧道协议（GTP-U)头部压缩， 形成压缩后的用户层面的通用分组无线业务隧 道协议（GTP-U)数据包， 所述压缩后的用户层面的通用分组无线业务隧道协 议（GTP-U)数据包中至少包含所述互联网协议（IP)头部、 用户数据报协议 (UDP)头部和用户层面的通用分组无线业务隧道协议（GTP-U)头部压缩后 形成的压缩头部， 所述压缩头部至少包括上下文标识（CID), 其中， 所述的 上下文标识（CID)与未压缩的包含相同的互联网协议（IP) 头部、 用户数据 报协议（UDP)头部和用户层面的通用分组无线业务隧道协议（GTP-U)头部 的用户层面的通用分组无线业务隧道协议（ GTP-U)数据包中的上下文标识 (CID)相同；
将所述多于一个用户层面的通用分组无线业务隧道协议（ GTP-U)数据包 中未压缩的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包和所述压 缩后形成的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包发送给接 收装置。
2、根据权利要求 1所述的方法， 其特征在于， 所述将数据封装为多于一个 用户层面的通用分组无线业务隧道协议（GTP-U)数据包之前， 所述方法还包 括：
获取压缩信息；
则所述将多于一个用户层面的通用分组无线业务隧道协议（ GTP-U )数据 包中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网 协议（IP)头部、 用户数据^艮协议（UDP)头部和用户层面的通用分组无线业 务隧道协议（GTP-U) 头部压缩具体为： 根据所述协商获取的压缩信息中的两次完整头部发送之间最多可发送的 压缩头数目， 将所述用户层面的通用分组无线业务隧道协议（GTP-U )数据包 组中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网 协议（IP )头部、 用户数据^艮协议（UDP )头部和用户层面的通用分组无线业 务隧道协议（GTP-U ) 头部压缩。
3、 根据权利要求 2所述的方法， 其特征在于， 所述将多于一个用户层面的 通用分组无线业务隧道协议（ GTP-U )数据包中未压缩的用户层面的通用分组 无线业务隧道协议（ GTP-U )数据包和所述压缩后形成的用户层面的通用分组 无线业务隧道协议（GTP-U )数据包发送给接收装置， 具体包括：
根据获取的压缩信息，将所述多于一个用户层面的通用分组无线业务隧道 协议 （GTP-U ) 数据包中未压缩的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包和所述压缩后形成的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包发送给接收装置。
4、根据权利要求 2所述的方法，其特征在于，所述获取压缩信息具体包括： 通过与接收装置协商， 从而获取压缩信息。
5、 根据权利要求 1所述的方法， 其特征在于， 所述压缩头部还包括： 数据 包序列号、用户数据报协议校验和、 隧道端点标识、互联网协议第四版（IPv4 ) 标识、 指示互联网协议第四版（ IPv4 )标识的参数 I和指示隧道端点标识的参 数丁。
6、 根据权利要求 1至 5任一项所述的方法， 其特征在于， 如果所述多于一 个用户层面的通用分组无线业务隧道协议（ GTP-U )数据包为多于一个符合 PPP 链路传输的用户层面的通用分组无线业务隧道协议（GTP-U )数据包；
所述将多于一个用户层面的通用分组无线业务隧道协议（ GTP-U )数据包 中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网协 议（IP )头部、 用户数据^艮协议（UDP )头部和用户层面的通用分组无线业务 隧道协议（GTP-U )头部压缩， 具体包括： 将多于一个用户层面的通用分组无 线业务隧道协议（ GTP-U )数据包中部分用户层面的通用分组无线业务隧道协 议（GTP-U )数据包中传输网络层互联网协议（IP )头部、 传输网络层用户数 据>¾协议（UDP)头部和用户层面的通用分组无线业务隧道协议（GTP-U)头 部压缩；
如果所述多于一个用户层面的通用分组无线业务隧道协议（ GTP-U )数据 包为多于一个符合路由组网环境中传输的用户层面的通用分组无线业务隧道 协议（GTP-U)数据包；
所述将多于一个用户层面的通用分组无线业务隧道协议（ GTP-U)数据包 中部分用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的互联网协 议（IP)头部、 用户数据^艮协议（UDP)头部和用户层面的通用分组无线业务 隧道协议（GTP-U)头部压缩， 具体包括： 将多于一个用户层面的通用分组无 线业务隧道协议（ GTP-U )数据包中部分用户层面的通用分组无线业务隧道协 议（GTP-U)数据包中的无线网络层互联网协议（IP)头部、 无线网络层用户 数据报协议（UDP) 头部和用户层面的通用分组无线业务隧道协议（GTP-U) 头部压缩。
7、 一种数据的传输方法， 其特征在于， 包括：
接收未压缩的用户层面的通用分组无线业务隧道协议（ GTP-U)数据包和 压缩后形成的用户层面的通用分组无线业务隧道协议（GTP-U)数据包， 所述 压缩后形成的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中至少 包括上下文标识（CID), 其中， 所述的上下文标识（CID)与未压缩的包含相 同的互联网协议 (IP)头部、 用户数据报协议（UDP)头部和用户层面的通用 分组无线业务隧道协议（GTP-U)头部的用户层面的通用分组无线业务隧道协 议（GTP-U)数据包中的上下文标识（CID)相同；
根据所述接收压缩后形成的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中的上下文标识（CID)与所述接收未压缩的用户层面的通 用分组无线业务隧道协议（GTP-U)数据包中的上下文标识（CID), 将所述 压缩后形成的用户层面的通用分组无线业务隧道协议（ GTP-U)数据包还原。
8、 一种通信设备， 其特征在于， 包括：
封装单元，用于将数据封装为多于一个用户层面的通用分组无线业务隧道 协议（GTP-U)数据包； 压缩单元，用于将所述封装后的多于一个用户层面的通用分组无线业务隧 道协议 （GTP-U) 数据包中部分用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中的互联网协议（IP)头部、 用户数据报协议（UDP)头部 和用户层面的通用分组无线业务隧道协议（GTP-U)头部压缩， 形成压缩后的 用户层面的通用分组无线业务隧道协议（GTP-U)数据包， 所述压缩后的 用 户层面的通用分组无线业务隧道协议（ GTP-U)数据包中至少包含所述互联网 协议（IP)头部、 用户数据^艮协议（UDP)头部和用户层面的通用分组无线业 务隧道协议（GTP-U)头部压缩后形成的压缩头部， 所述压缩头部至少包含上 下文标识（CID), 所述上下文标识（CID)与未压缩的数据包中的上下文标识 (CID)相同， 用于接收装置解压缩所述压缩后的用户层面的通用分组无线业 务隧道协议（GTP-U)数据包；
发送单元， 用于发送未压缩的用户层面的通用分组无线业务隧道协议 ( GTP-U ) 数据包， 发送压缩后的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包。
9、 根据权利要求 8所述的通信设备， 其特征在于，
所述封装单元， 具体用于将数据封装为多于一个符合在点对点协议 PPP链 路上传输的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包， 所述的 用户层面的通用分组无线业务隧道协议（GTP-U)数据包中包含上下文标识 ( CID );
所述压缩单元，具体用于将所述封装后的多于一个用户层面的通用分组无 线业务隧道协议（ GTP-U)数据包中部分用户层面的通用分组无线业务隧道协 议（GTP-U)数据包中的传输网络层互联网协议（IP)头部、 传输网络层用户 数据报协议（UDP) 头部和用户层面的通用分组无线业务隧道协议（GTP-U) 头部压缩， 形成压缩后的用户层面的通用分组无线业务隧道协议（GTP-U)数 据包， 所述压缩后的 用户层面的通用分组无线业务隧道协议（GTP-U)数据 包中至少包含所述传输网络层互联网协议（IP)头部、 传输网络层用户数据报 协议（UDP)头部和用户层面的通用分组无线业务隧道协议（GTP-U)头部压 缩后形成的压缩头部， 所述压缩头部至少包括上下文标识（CID), 所述上下 文标识（CID )用于接收装置解压缩所述压缩后的用户层面的通用分组无线业 务隧道协议（GTP-U )数据包。
10、 根据权利要求 8所述的通信设备， 其特征在于，
所述封装单元，具体用于将数据封装为多于一个符合在路由组网环境中传 输的用户层面的通用分组无线业务隧道协议（GTP-U )数据包， 所述的用户层 面的通用分组无线业务隧道协议（GTP-U )数据包中包含上下文标识（CID )。
所述压缩单元，具体用于将所述封装后的多于一个用户层面的通用分组无 线业务隧道协议（ GTP-U )数据包中部分用户层面的通用分组无线业务隧道协 议（GTP-U )数据包中的无线网络层互联网协议（IP )头部、 无线网络层用户 数据 协议（ UDP ) 头部和用户层面的通用分组无线业务隧道协议（ GTP-U ) 头部压缩， 形成压缩后的用户层面的通用分组无线业务隧道协议（GTP-U )数 据包， 所述压缩后的 用户层面的通用分组无线业务隧道协议（GTP-U )数据 包中至少包含所述无线网络层互联网协议（IP )头部、 无线网络层用户数据报 协议（UDP )头部和用户层面的通用分组无线业务隧道协议（GTP-U )头部压 缩后形成的压缩头部， 所述压缩头部至少包含上下文标识（CID ), 所述上下 文标识（CID )用于接收装置解压缩所述压缩后的用户层面的通用分组无线业 务隧道协议（GTP-U )数据包。
11、根据权利要求 10所述的通信设备，其特征在于，所述通信设备还包括: 协商单元或者获取单元其中任一项； 其中，
所述协商单元， 用于与接收设备协商压缩信息， 从而获取压缩信息； 所述获取单元， 用于获取预置的压缩信息；
则所述压缩单元， 具体用于根据获取的压缩信息，将所述封装后的多于一 个用户层面的通用分组无线业务隧道协议（ GTP-U )数据包中部分用户层面的 通用分组无线业务隧道协议（ GTP-U )数据包中的无线网络层互联网协议（ IP ) 头部、 无线网络层用户数据 协议（ UDP )头部和用户层面的通用分组无线业 务隧道协议（GTP-U )头部压缩， 形成压缩后的用户层面的通用分组无线业务 隧道协议（GTP-U )数据包， 所述压缩后的 用户层面的通用分组无线业务隧 道协议（GTP-U )数据包中至少包含所述无线网络层互联网协议（IP ) 头部、 无线网络层用户数据报协议（ UDP )头部和用户层面的通用分组无线业务隧道 协议（GTP-U )头部压缩后形成的压缩头部， 所述压缩头部至少包含上下文标 识（ CID ) , 所述上下文标识（ CID )用于接收装置解压缩所述压缩后的用户层 面的通用分组无线业务隧道协议（GTP-U )数据包。
则所述发送单元， 具体用于根据获取的压缩信息，将所述多于一个用户层 面的通用分组无线业务隧道协议（ GTP-U )数据包中未压缩的用户层面的通用 分组无线业务隧道协议（ GTP-U )数据包和所述压缩后形成的用户层面的通用 分组无线业务隧道协议（GTP-U )数据包发送给接收装置。
12、 一种接收装置， 其特征在于， 包括：
第三接收单元，用于接收发送装置发送未压缩的用户层面的通用分组无线 业务隧道协议（ GTP-U )数据包和压缩后的用户层面的通用分组无线业务隧道 协议（GTP-U )数据包， 所述为压缩的用户层面的通用分组无线业务隧道协议 ( GTP-U )数据包中包含上下文标识（ CID );
解压缩单元，用于根据所述接收压缩后形成的用户层面的通用分组无线业 务隧道协议（GTP-U )数据包中的上下文标识（CID )与所述接收未压缩的用 户层面的通用分组无线业务隧道协议（ GTP-U )数据包中的上下文标识（ CID ), 将所述压缩后的用户层面的通用分组无线业务隧道协议（ GTP-U )数据包还原。
13、 根据权利要求 12所述的装置， 其特征在于， 所述装置还包括： 第三协商单元， 用于与所述发送装置进行协商，从而产生协商压缩信息的 结果；
所述解压缩单元， 具体用于根据所述协商压缩信息的结果，将所述压缩后 的用户层面的通用分组无线业务隧道协议（GTP-U )数据包还原。
14、 根据权利要求 12所述的装置， 其特征在于， 所述装置还包括： 第三获取单元， 用于获取预置的压缩信息；
则所述解压缩单元， 具体用于根据所述压缩信息，将所述压缩后的用户层 面的通用分组无线业务隧道协议（GTP-U )数据包还原。
15、 一种通信***， 其特征在于， 所述通信***包括： 发送装置和接收装 置，
所述发送装置， 为如权利要求 8至 11任一项所述的通信设备；
所述接收装置， 为如权利要求 12至 14任一项所述的接收装置。
PCT/CN2009/073439 2008-08-22 2009-08-24 一种数据的传输方法、通信设备及通信*** WO2010020197A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810042023.3 2008-08-22
CN 200810042023 CN101350812B (zh) 2008-08-22 2008-08-22 一种数据的传输方法、通信设备及通信***

Publications (1)

Publication Number Publication Date
WO2010020197A1 true WO2010020197A1 (zh) 2010-02-25

Family

ID=40269389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073439 WO2010020197A1 (zh) 2008-08-22 2009-08-24 一种数据的传输方法、通信设备及通信***

Country Status (2)

Country Link
CN (1) CN101350812B (zh)
WO (1) WO2010020197A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112566180A (zh) * 2020-12-09 2021-03-26 东方通信股份有限公司 一种提升tetra***分组数据传输速率的方法
CN113746670A (zh) * 2021-08-12 2021-12-03 中国电子科技集团公司电子科学研究院 基于网管服务器的跨域网络管理方法及跨域网络管理装置

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101350812B (zh) * 2008-08-22 2012-06-27 上海华为技术有限公司 一种数据的传输方法、通信设备及通信***
CN102369753B (zh) * 2009-05-19 2014-08-06 华为技术有限公司 语音包发送、接收的方法、装置和***
CN101998511B (zh) * 2009-08-26 2013-04-24 华为技术有限公司 网络中继场景下的头压缩方法及装置
CN102118791B (zh) * 2009-12-31 2014-01-08 华为技术有限公司 一种传输数据包的方法及装置
CN102413506B (zh) * 2010-09-20 2015-04-15 华为技术有限公司 一种压缩方法与装置
CN103873443B (zh) * 2012-12-13 2018-04-27 联想(北京)有限公司 信息处理方法、本地代理服务器和网络代理服务器
CN104394117A (zh) * 2014-03-10 2015-03-04 贵阳朗玛信息技术股份有限公司 Rtp包的传输方法及装置
RU2645283C1 (ru) * 2014-05-28 2018-02-19 Хуавэй Текнолоджиз Ко., Лтд. Способ и устройство адаптации стека протоколов
WO2017113342A1 (zh) * 2015-12-31 2017-07-06 华为技术有限公司 数据包传输方法及装置
CN107172662A (zh) * 2017-07-24 2017-09-15 京信通信***（中国）有限公司 一种通信方法及装置
WO2020164611A1 (en) * 2019-02-14 2020-08-20 Mediatek Inc. Simple ethernet header compression
CN110740222A (zh) * 2019-09-27 2020-01-31 安徽延达智能科技有限公司 一种消防机器人用远距离图传方法
CN113381920B (zh) * 2020-03-09 2022-11-22 ***通信有限公司研究院 一种数据传输方法、节点和存储介质
CN113518386A (zh) * 2020-04-09 2021-10-19 华为技术有限公司 Gprs隧道协议gtp包的处理方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1545783A (zh) * 2001-06-27 2004-11-10 ��˹��ŵ�� 数据包连接上报头压缩标识符的传输
CN1777175A (zh) * 2005-08-20 2006-05-24 海信集团有限公司 移动通信中ip数据压缩的方法
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信***

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100574526C (zh) * 2004-06-29 2009-12-23 中兴通讯股份有限公司 移动通信网络中减少用户冗余数据的网络侧激活方法
CN1889575B (zh) * 2006-07-18 2010-05-12 华为技术有限公司 在ip层实现头压缩及复用的方法
CN101212404B (zh) * 2006-12-27 2011-04-06 大唐移动通信设备有限公司 鲁棒头压缩分组数据传输的方法及***

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1545783A (zh) * 2001-06-27 2004-11-10 ��˹��ŵ�� 数据包连接上报头压缩标识符的传输
CN1777175A (zh) * 2005-08-20 2006-05-24 海信集团有限公司 移动通信中ip数据压缩的方法
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信***

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112566180A (zh) * 2020-12-09 2021-03-26 东方通信股份有限公司 一种提升tetra***分组数据传输速率的方法
CN113746670A (zh) * 2021-08-12 2021-12-03 中国电子科技集团公司电子科学研究院 基于网管服务器的跨域网络管理方法及跨域网络管理装置
CN113746670B (zh) * 2021-08-12 2023-07-21 中国电子科技集团公司电子科学研究院 基于网管服务器的跨域网络管理方法及跨域网络管理装置

Also Published As

Publication number Publication date
CN101350812B (zh) 2012-06-27
CN101350812A (zh) 2009-01-21

Similar Documents

Publication Publication Date Title
WO2010020197A1 (zh) 一种数据的传输方法、通信设备及通信***
JP6025880B2 (ja) データ伝送方法、装置及びシステム
JP3751823B2 (ja) 実時間サービスにおけるヘッダ圧縮
JP3834001B2 (ja) データパケット接続のヘッダフィールド圧縮の定義方法
EP1486039B1 (en) Method and apparatus for header compression in a wireless lan
TWI788627B (zh) 封包發送方法、封包接收方法以及相關設備
US20120155375A1 (en) Method and Apparatus for Header Compression in Network Relay Scenario
CN101369977A (zh) 数据传输的方法、装置和***
US9219537B2 (en) Method and system for transmitting information in relay communication network
KR20060054662A (ko) 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법
CN111092854B (zh) 用于将从源设备发送的分组发送到目的地设备的方法
WO2011079785A1 (zh) 一种传输数据包的方法及装置
WO2020220328A1 (zh) 无线通信的方法和设备
CN109526030A (zh) 报文的处理方法、装置和设备
US8559463B2 (en) Systems and methods for providing efficient bandwidth utilization in packet switched networks
Ertekin et al. Internet protocol header compression, robust header compression, and their applicability in the global information grid
CN100477568C (zh) 一种移动分组网络的数据传输方法
CN102118791B (zh) 一种传输数据包的方法及装置
KR100689473B1 (ko) 통신시스템에서 프로토콜 헤더 압축장치 및 방법
JP2005252855A (ja) ヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法
CN115002833B (zh) 以太帧的发送方法、接收方法、装置、设备和介质
CN109257772A (zh) 一种rtp数据的发送、接收方法及用户设备
CN100414926C (zh) 码分多址网络上实现分组数据压缩的方法及***
Rawat et al. Designing a tunneling header compression (TuCP) for tunneling over IP
JP3993869B2 (ja) データ変換装置、信号、データ変換方法、ｄｃｅおよびゲートウェイ

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09807896

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09807896

Country of ref document: EP

Kind code of ref document: A1