WO2011023124A1 - 网络中继场景下的头压缩方法及装置 - Google Patents

网络中继场景下的头压缩方法及装置 Download PDF

Info

Publication number
WO2011023124A1
WO2011023124A1 PCT/CN2010/076396 CN2010076396W WO2011023124A1 WO 2011023124 A1 WO2011023124 A1 WO 2011023124A1 CN 2010076396 W CN2010076396 W CN 2010076396W WO 2011023124 A1 WO2011023124 A1 WO 2011023124A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
udp
data packet
relay node
compressed
Prior art date
Application number
PCT/CN2010/076396
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 华为技术有限公司
Priority to ES10811284.8T priority Critical patent/ES2489469T3/es
Priority to EP10811284.8A priority patent/EP2464063B1/en
Publication of WO2011023124A1 publication Critical patent/WO2011023124A1/zh
Priority to US13/405,032 priority patent/US20120155375A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/155—Ground-based stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations

Definitions

  • Relay technology is based on the original site, by adding some new Relay stations (or relay nodes, RN) to increase the distribution density of stations and antennas.
  • These new relay nodes and the original base station (the parent base station) are all connected by wireless, and there is no wired connection between the transmission network, and the downlink data arrives at the parent base station first, and then transmitted to the relay node, and the relay node transmits to the terminal.
  • User, the upstream is the opposite. This approach narrows the distance between the antenna and the end user, improving the link quality of the terminal, thereby improving the spectrum efficiency and user data rate of the system.
  • IPv6 uses a 128-bit address space and obtains a mobile IPv6 mechanism through some extended headers, enabling IP (Internet Protocol)-based devices to move seamlessly between different wireless cells.
  • IP Internet Protocol
  • large address spaces and extended headers increase the transfer overhead.
  • transmitting too long headers wastes a lot of already very tight wireless link bandwidth. Therefore, how to efficiently transmit IPv6 packets becomes a key issue in mobile IP.
  • One solution is to use header compression technology. The header compression is simply referred to as header compression.
  • the embodiment of the invention provides a header compression method and device in a network relay scenario, so that header compression can be performed in a network relay scenario.
  • the embodiment of the invention provides a header compression method in a network relay scenario, which includes:
  • the relay node receives the header-compressed first data packet sent by the user equipment or other relay node, encapsulates a transport protocol packet header to the first data packet, and performs header compression on the packet header to form a second data packet;
  • the embodiment of the invention further provides a header compression method in a network relay scenario, including
  • the embodiment of the invention provides a relay node, which is characterized in that it comprises:
  • a receiving unit configured to receive a header-compressed first data packet sent by a user equipment or another relay node
  • a packet compression unit configured to encapsulate a transport protocol header for the first data packet, and perform header compression on the packet header to form a second data packet;
  • a sending unit configured to send the second data packet to a base station or a next relay node in an uplink direction.
  • the relay node receives the header-compressed first data packet sent by the user equipment or other relay node, encapsulates the transport protocol packet header on the first data packet, and performs header compression on the packet header to form second data.
  • the second data packet is sent to the base station or the next relay node in the uplink direction; thereby solving and implementing the header compression function, reducing the air interface bandwidth occupation and improving the spectrum utilization.
  • 1 is a flowchart of a header compression method in a network relay scenario according to an embodiment of the present invention
  • FIG. 2 is a user plane protocol stack of a relay node and a Donor eNobeB in a typical Relay scenario.
  • FIG. 3 is a schematic diagram of a header compression method in a network relay scenario according to an embodiment of the present invention
  • Figure 3b shows the frame structure of the IP header compressed between the UE and the relay node in the corresponding embodiment of Figure 3a;
  • Figure 3c shows the frame structure of the IP header compressed between the relay node and the eNodeB in the corresponding embodiment of Figure 3a;
  • FIG. 3 is a schematic diagram of a compression parameter configuration process required in the corresponding embodiment of FIG. 3a;
  • FIG. 4a is a schematic diagram of a header compression method in another network relay scenario according to an embodiment of the present invention.
  • Figure 4b shows the frame structure of the IP header compressed between the UE and the relay node in the corresponding embodiment of Figure 4a;
  • Figure 4c shows the frame structure of the IP header compressed between the relay node and the eNodeB in the corresponding embodiment of Figure 4a;
  • FIG. 4d is a schematic diagram showing a configuration process of the required compression parameters in the corresponding embodiment of FIG. 4a
  • FIG. 4e is a schematic diagram showing another configuration process of the required compression parameters in the corresponding embodiment of FIG. 4a;
  • Figure 5b shows the frame structure of the IP header compressed between the UE and the relay node in the corresponding embodiment of Figure 5a;
  • Figure 5c shows the frame structure of the IP header compressed between the relay node and the eNodeB in the corresponding embodiment of Figure 5a;
  • FIG. 5d is a schematic diagram showing a process of configuring a compression parameter required in the corresponding embodiment of FIG. 5a;
  • FIG. 6 is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present invention.
  • Figure 6b shows the frame structure of the IP header compressed between the UE and the relay node in the corresponding embodiment of Figure 6a;
  • Figure 6c shows the frame structure of the IP header compressed between the relay node and the eNodeB in the corresponding embodiment of Figure 6a;
  • FIG. 7 is a schematic diagram of a header compression method in a network relay scenario according to an embodiment of the present invention.
  • Figure 7b shows the frame structure of the IP header compressed between the UE and the relay node 1 in the corresponding embodiment of Figure 7a;
  • Figure 7c shows the frame structure of the IP header compressed between the relay node 1 and the relay node 2 in the corresponding embodiment of Figure 7a;
  • Figure 7d shows the frame structure of the IP header compressed between the relay node 2 and the eNodeB in the corresponding embodiment of Figure 7a;
  • FIG. 8 is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present disclosure.
  • Figure 9a is a schematic diagram showing the frame structure of a UDP packet
  • Figure 9b shows a schematic diagram of a frame structure of IPv4
  • Figure 9c is a schematic diagram of a frame structure of IPv6
  • FIG. 10 is a schematic structural diagram of a relay node according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS In order to make the objects, technical solutions and advantages of the embodiments of the present invention more comprehensible, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings.
  • FIG. 1 is a flowchart of a header compression method in a network relay scenario according to an embodiment of the present invention, including: 101. Receive a header-compressed first data packet sent by a user equipment or another relay node,
  • the foregoing transmission protocol specifically includes: a tunnel protocol and a tunnel protocol transmission protocol; wherein the tunnel protocol includes: GTP-U (GPRS Tunneling Protocol - User plane, general packet radio service technology tunneling protocol-user plane); IP/UDP (User Datagram Protocol, User Datagram Protocol)
  • GTP-U GPRS Tunneling Protocol - User plane, general packet radio service technology tunneling protocol-user plane
  • IP/UDP User Datagram Protocol, User Datagram Protocol
  • the protocol header is used to be encapsulated in the GTP-U tunneling protocol, where the IP protocol and the UDP protocol are used to carry the tunneling protocol.
  • step 102 may be:
  • IP/UDP/APP After decompressing the header of the first data packet, compressing the header of the decompressed first data packet by using IP/UDP/APP. compression algorithm and IP/UDP/GTP-U compression algorithm respectively, respectively forming two
  • the second packet of the segment header is compressed; or, the IP/UDP/APP. and IP/UDP/GTP-U headers are compressed in a compressed header to form the second packet.
  • the method may be: encapsulating an IP/UDP/GTP-U packet header outside the IP/UDP/APP. header of the header compressed first data packet to form the second data packet.
  • the relay node when there is a relay node between the UE and the network, and the relay node and the network are still wireless interfaces, the relay node separately performs packet header compression of the data packet with the UE. Header compression of packets between the relay node and the eNodeB entity. The problem of excessive bandwidth occupied by data packets in the network relay scenario is solved. By applying header compression on the RN and the eNB and the UE, the bandwidth consumption of the air interface is reduced, and the spectrum utilization rate is improved.
  • the method provided by the embodiment of the present invention is introduced in conjunction with a specific Relay scenario. It should be noted that the embodiments of the present invention are also applicable to other Relay scenarios.
  • the user interface protocol stack architecture of the relay node and Donor eNobeB in a typical Relay scenario involves: App. (application protocol), TCP (Transfer Control Protocol) Protocol), UDP, PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Media Access Control), PHY (Physical Layer) Layer), GTP-U, etc., where App. (application protocol) specifically includes: RTP (Real Time Transport Protocol), HTTP (Hypertext Transfer Protocol), or FTP (File Transport Protocol) Agreement) and so on.
  • App. application protocol specifically includes: RTP (Real Time Transport Protocol), HTTP (Hypertext Transfer Protocol), or FTP (File Transport Protocol) Agreement) and so on.
  • IP/UDP/APP In the present invention, IP/UDP/APP.
  • FIG. 3a is a schematic diagram of a header compression method in a network relay (Relay) scenario according to an embodiment of the present invention; in order to clearly distinguish between a compressed portion and a decompressed portion, a dotted shadow is used in the drawing to represent a compressed portion.
  • CID stands for Context Identifier. Since multiple contexts can be maintained in one payload, it is necessary to use context identifiers for one media stream to distinguish different header compression processes. Among them, in the ROHC protocol, the CID is a binary number from 0 - 15 bits.
  • CID X represents that an IP/UDP/APP.
  • header header compression context identified by the Context Identifier as X is established between the UE and the relay node;
  • CID X represents establishment between the relay node and the eNodeB.
  • Use the Context Identifier to be X identify the IP/UDP/APP.
  • CID Y represents the IP/UDP/GTP-U header header compression context that is established between the relay node and the eNodeB with the Context Identifier identified by Y.
  • CID X, CID X, and CID Y represent different context identifiers, respectively.
  • the media sent by the UE is compressed on the user plane using a header compression algorithm and is unpacked on the relay node.
  • the user plane data sent to the Doner eNodeB entity is compressed separately using the IP/UDP/APP.compression profile (algorithm) and the IP/UDP/GTP-U compression profile, respectively, and the eNodeB entity unpacks the IP.
  • the header is sent to the next network entity, such as the Serving GATEWAY or the PDN GATEWAY. Among them, IP / UDP / APP.
  • the meanings in other embodiments of the present invention are the same as those described above, and are not described again.
  • the above Doner eNodeB is a primary base station that provides signals for the Relay node, hereinafter referred to as an eNodeB.
  • a context relationship (Context) of a compressed profile of a compressed IP/UDP/APP. packet header is established between the UE and the relay node, and an IP/UDP/GTP-U header is compressed between the relay node and the eNodeB. Profile context.
  • the frame structure of the compressed IP header that establishes the ROHC compression context between the UE and the relay node is as shown in Figure 3b.
  • Figure 3d shows a process of configuring a compression parameter, or a negotiation process, in the compression process of the embodiment, involving RRC (Radio Resource Control), S1-AP (S1 interface), SCTP (Stream Control Transmission Protocol), NAS (Non Access Stratum, non-access stratum).
  • RRC Radio Resource Control
  • S1-AP S1 interface
  • SCTP Stream Control Transmission Protocol
  • NAS Non Access Stratum, non-access stratum
  • the relay node acts as a terminal, and the S1-AP interface can also be used to negotiate the header compression parameters, including:
  • the UE sends a DRB (Dedicate Radio Bearer) configuration including ROHC parameters (arameters), and the ROHC parameters sent at this time include a compression mechanism, such as ROHC compression, and a profile of the compressed packet header, such as IP. /UDP/APP..
  • the ROHC compressed profile supported by the UE is a separate IP/UDP/App. compressed profile, IP/TCP, IP/UDP and other compressed profiles.
  • the PDCP parameter represents the ability of the UE to support header compression.
  • the profile of the compressed header refers to a compression algorithm of the compression mechanism for a certain type of packet header combination.
  • prf.03 Algorithm 03
  • the ROHC parameter sent by the UE includes Profile 0x0001, which means that the UE requests to perform on the established DRB. ROHC compression for Profile 0x0001 is supported.
  • the relay node receives the ROHC parameter sent by the UE, such as ROHC compression, and the compressed packet.
  • the reconfiguration can be sent to the UE, and the network reconfiguration includes the PDCP parameter, and the PDCP parameter includes the ROHC compression parameter supported by the DRB reconfigured by the DRB and the profile of the compressed packet header.
  • the frame structure of the compressed IP header is shown in Figure 3b.
  • step 302 may appear after step 301, or may be performed after the relay node completes step 303 in the process.
  • This process establishes a ROHC compressed context (Context) between the UE and the relay node.
  • the user plane data sent between the relay node and the eNodeB except for the payload, the LI header (Layer 1 header) And; L2 header (Layer 2 header), and the IP/UDP/APP. header shown in the figure, the user plane also includes the IP/UDP/GTP-U header.
  • the IP/UDP/GTP-U header is also compressed.
  • the relay node sends the supported ROHC parameters to the eNodeB.
  • the ROHC parameters sent at this time include a compression mechanism, such as ROHC compression, and a profile of the compressed header, where the compressed profiles include IP/UDP/GTP-U compressed profile identifiers and IPs, respectively. /UDP/APP. Compresses rofile support, indicating that the relay node supports and requests IP/UDP/GTP-U compression and IP/UDP/APP. compression respectively in the requested DRB.
  • the eNodeB compresses the ROHC, and the IP/UDP/GTP-U compressed profile identifier and the IP/UDP/APP. compressed profile of the compressed packet header, and can send reconfiguration to the relay node, in network reconfiguration.
  • the PDCP parameters are included, and the PDCP parameters include the ROB compression parameters supported by the DRB reconfiguration and the IP/UDP/GTP-U compressed profile identifier and the IP/UDP/APP. compressed profile of the compressed header.
  • the frame structure of the compressed IP header is shown in Figure 3c:
  • This process establishes a nested two-layer ROHC compressed context relationship between the eNodeB and the relay node.
  • FIG. 4a is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present invention; in order to clearly distinguish between a compressed portion and a decompressed portion, a dotted shadow is used in the drawing to represent a compressed portion.
  • the media sent by the UE is compressed on the user plane by using an IP/UDP/App. header compression algorithm, and the relay node does not unpack the compressed IP/UDP/App. header, and the compressed IP/ The UDP/App. packet header is sent to the eNodeB entity.
  • the relay node receives the compressed data packet, encapsulates the IP/UDP/GTP-U header in the packet header, and performs header compression on the IP/UDP/GTP-U header to send to the eNodeB entity.
  • the eNodeB entity decompresses the received compressed IP UDP/GTP-U header and IP/UDP/App. header respectively and sends them to the next network entity.
  • a compression context relationship is not established between the UE and the relay node; a compressed profile context of the IP/UDP/GTP-U header is established between the relay node and the eNodeB; an IP is established between the UE and the eNodeB.
  • the compressed profile context of the UDP/App. header is not established between the UE and the relay node;
  • the frame structure of the compressed IP header transmitted by the UE and the relay node is as shown in FIG. 4b, and the compressed IP UDP/App. header and Payload portion of the IP packet of the frame structure are directly sent by the relay node to the relay node.
  • eNodeB entity The frame structure of the compressed IP header transmitted by the UE and the relay node is as shown in FIG. 4b, and the compressed IP UDP/App. header and Payload portion of the IP packet of the frame structure are directly sent by the relay node to the relay node.
  • the frame structure of the compressed IP header that establishes a nested two-layer ROHC compressed context (Context) between the relay node and the eNodeB is shown in Figure 4c, where the IP/UDP/App. header is directly used by the relay node. Forwarding the header compressed by the UE entity, the IP/UDP/GTP-U header is the header encapsulated by the relay node.
  • the ROHC compression supports the context relationship of the IP/UDP/APP.compression profile between the UE and the eNodeB, and the relay node receives the compressed IP/UDP/APP.
  • the header is sent directly to the eNodeB entity, and the eNodeB entity is responsible for unpacking the IP/UDP/APP. Compression header; at the same time, the relay node adds the packet to the eNodeB.
  • the TP/UDP/GTP-U header is entered, and TP/UDP/GTP-U compression profHe is executed.
  • FIG. 4d is a view showing a process of configuring a compression parameter required in the compression process according to the embodiment, which specifically includes:
  • the UE sends a DRB configuration including a ROHC parameter.
  • the ROHC parameter sent at this time includes a compression mechanism, such as ROHC compression, and a profile of the compressed header, such as IP/UDP/APP.
  • the ROHC compressed profile supported by the UE is a separate IP/UDP/APP. compressed profile, IP/TCP, IP/UDP, etc. compression profile.
  • the PDCP parameter represents the ability of the UE to support header compression.
  • the profile of the compressed header refers to a compression algorithm of the compression mechanism for a certain type of packet header combination.
  • the relay node receives the ROHC parameter sent by the UE, such as ROHC compression, and the profile of the compressed header.
  • the relay node sends the received ROHC parameters to the eNodeB entity for the purpose of performing head-to-head compression with the air interface of the eNodeB entity, and the ROHC parameters supported by the DRB requested by the ROHC parameter UE and the profile of the compressed header.
  • the user plane also includes the IP/UDP/GTP-U header.
  • the IP/UDP/GTP-U header is also compressed.
  • the ROHC parameters that the relay node sends to the eNodeB support include the IP/UDP/GTP-U compressed profile identifier, indicating that the relay node supports and requests to apply IP/UDP/GTP-U compression and UE-requested IP in the requested DRB, respectively. /UDP/APP. Compression.
  • IP/UDP/GTP-U compressed profile identifier and IP/UDP/APP.compression profile which can send reconfiguration to the relay node.
  • the network reconfiguration includes PDCP parameters.
  • the PDCP parameters include the ROHC compression parameters supported by the DRB reconfiguration DRB.
  • the IP/UDP/GTP-U compressed profile identifier and the IP/UDP/APP. compressed profile of the compressed header are included in the compressed header.
  • the relay node sends a PDCP parameter to the UE, and may send a reconfiguration to the UE.
  • the network reconfiguration includes a PDCP parameter, and the PDCP parameter includes a DRB supported by the DRB reconfiguration.
  • the parameter and the profHe of the compressed header is shown in Figure 4c.
  • This process can establish a nested two-layer ROHC compressed context (Context) between the UE and the relay node and the eNodeB.
  • Context a nested two-layer ROHC compressed context
  • FIG. 4e is another embodiment of the compression parameter configuration process required in the compression process of the embodiment, which specifically includes:
  • the UE sends the establishment DRC configuration includes the ROHC parameter, and the ROHC parameter sent at this time includes a compression mechanism, such as ROHC compression, and a profile of the compressed header, such as IP/UDP/APP.
  • the ROHC compressed profile supported by the UE is a separate IP/UDP/APP. compressed profile, IP/TCP, IP/UDP, etc. compression profile.
  • the PDCP parameter represents the ability of the UE to support header compression.
  • the profile of the compressed header refers to a compression algorithm of the compression mechanism for a certain type of packet header combination.
  • the relay node sends a PDCP parameter to the UE, and may send a reconfiguration to the UE.
  • the network reconfiguration includes a PDCP parameter, where the PDCP parameter includes a DRHC supported ROHC compression parameter of the DRB reconfiguration and a profile of the compressed packet header.
  • the frame structure of the compressed IP header is shown in Figure 4c.
  • the relay node may perform a header compression mechanism between the relay node and the air interface of the eNodeB entity, and the received slave UE.
  • the transmitted ROHC parameters are sent to the eNodeB entity, and the ROHC parameters requested by the DRB are supported by the DRHC and the profile of the compressed header.
  • the user plane also includes the IP/UDP/GTP-U header.
  • the IP/UDP/GTP-U header is also compressed.
  • the relay node sends the supported ROHC parameters to the eNodeB while transmitting the ROHC parameters received from the UE to the eNodeB entity, including the IP/UDP/GTP-U compressed profile identifier, indicating that the relay node supports and requests in the requested DRB.
  • IP/UDP/GTP-U compression and UE-requested IP/UDP/APP. compression are applied separately.
  • eNodeB received ROHC parameters, such as ROHC compression, and compressed headers
  • the reconfiguration can be sent to the relay node, and the network reconfiguration includes the PDCP parameter, and the PDCP parameter includes the ROB compression supported by the DRB reconfiguration DRB.
  • This process can establish a nested two-layer ROHC compressed context (Context) between the UE and the relay node and the eNodeB.
  • Context a nested two-layer ROHC compressed context
  • FIG. 5a is a schematic diagram of a header compression method in another network relay scenario according to an embodiment of the present invention; in order to clearly distinguish between a compressed portion and a decompressed portion, a dotted shadow is used in the drawing to represent a compressed portion.
  • the media sent by the UE is compressed on the user plane using a header compression algorithm and is unpacked on the relay node.
  • the user plane data sent by the relay node to the eNodeB entity is compressed using the IP/UDP/APP. ⁇ IP/UDP/GTP-U header compression profile, the eNodeB entity unpacks the IP header, and sends the decompressed data packet to the next An entity.
  • a context relationship of a compressed profile of the compressed IP/UDP/APP. header is established between the UE and the relay node; IP/UDP/APP. and IP/UDP/GTP are established between the relay node and the eNodeB. -U header compression profile relationship.
  • Figure 5d shows the compression parameter configuration process required during the compression process of the embodiment, or It is called the negotiation process and includes:
  • the UE sends the DRB configuration to include the ROHC parameter, and the ROHC parameter sent at this time includes a compression mechanism, such as ROHC compression, and a profile of the compressed packet header, such as IP/UDP/APP.
  • the ROHC compressed profile supported by the UE is a separate IP/UDP/App. compression profile, IP/TCP, IP/UDP, etc. compression profile.
  • the PDCP parameter represents the ability of the UE to support header compression.
  • the profile of the compressed header refers to a compression algorithm of the compression mechanism for a certain type of packet header combination.
  • the relay node receives the ROHC parameter sent by the UE, such as the ROHC compression, and the profile of the compressed packet header, and may send the reconfiguration to the UE, where the network reconfiguration includes the PDCP parameter, and the PDCP parameter includes the DRB supported by the DRB reconfiguration.
  • ROHC compression parameters and profile of the compressed header The frame structure of the compressed IP header is shown in Figure 5b;
  • step 502 may appear after step 501, or may be performed after the step 503 is completed in the process.
  • This process establishes a ROHC compressed context (Context) between the UE and the relay node.
  • the user plane Performing a header compression mechanism between the relay node and the air interface of the eNodeB entity, the user plane data sent between the relay node and the eNodeB, except for the payload, the Layer 1 and the Layer 2 header, and the figure
  • the user plane also includes the IP/UDP/GTP-U header.
  • the IP/UDP/GTP-U header is also compressed together.
  • the relay node sends the supported ROHC parameters to the eNodeB.
  • the ROHC parameters sent at this time include a compression mechanism, such as ROHC compression, and a profile of the compressed header, where the compressed profile includes compressed IP/UDP/GTP-U and IP/UDP/
  • the compressed profile indication of the APP. header indicates that the relay node supports and requests to apply IP/UDP/GTP-U and IP/UDP/APP.compression profiles in the requested DRB.
  • the eNodeB compresses the ROHC, and the IP/UDP/GTP-U and IP/UDP/APP. compressed profiles of the compressed packet header, and can send reconfiguration to the relay.
  • the configuration includes a PDCP parameter, which includes a ROB compression parameter supported by the DRB of the DRB reconfiguration and an IP/UDP/GTP-U, IP/UDP/APP. compression profile of the compressed packet header.
  • the frame structure of the compressed IP header is shown in Figure 5c; this process can establish a nested two-layer ROHC compressed context (Context) between the eNodeB and the relay node.
  • FIG. 6a is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present invention; in order to clearly distinguish between a compressed portion and a decompressed portion, a dotted shadow is used in the drawing to represent a compressed portion.
  • the data sent by the plurality of user terminals UEs performs header compression of the IP/UDP/App. header between the UE and the relay node.
  • the data of the relay node to the eNodeB encapsulates the IP header sent by multiple UEs with the same IP/UDP/GTP-U header, and performs a header compression profile algorithm of the IP/UDP/GTP-U header.
  • the header compression process in Embodiment 3 is used, that is, the relay node sends the received IP packets sent by UE1 and UE2 directly to the eNodeB entity.
  • the UE and the relay node do not Establish a compression context relationship; establish a compressed profile context of the IP/UDP/GTP-U header between the relay node and the eNodeB; establish a compressed profile context of the IP/UDP/App. header between UE1 and UE2 and the eNodeB.
  • the frame structure of the compressed IP header transmitted by the UE and the relay node is as shown in Fig. 6b; the IP packet of this frame structure is directly sent by the relay node to the eNodeB entity.
  • the frame structure of the compressed IP header that establishes a nested two-layer ROHC compressed context (Context) between the relay node and the eNodeB is as shown in FIG. 6c; wherein the IP/UDP/App. header is a relay node.
  • the packet header compressed by the UE entity is directly forwarded, and the IP/UDP/GTP-U packet header is a packet header encapsulated by the relay node.
  • the identifier of the data sent by the UE1 and the UE2 is used to distinguish the data packet, and the identifier of the data packet may be an IP address, a port number, a user identifier, a header compression context identifier, and the like.
  • the UE and the relay node may also be implemented according to the method described in the embodiment corresponding to FIG. 3, that is, the compressed IP/UDP/App. header sent by the UE, in the relay section. The point is unlocked; then, when the relay node transmits the data packet, the compression is performed according to the compression method of the embodiment, as shown in the frame structure of Figs. 6b and 6c.
  • FIG. 7a is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present invention; in order to clearly distinguish between a compressed portion and a decompressed portion, a dotted shadow is used in the drawing to represent a compressed portion.
  • the data packets sent by the UE are sent to the eNodeB through the relay node 1 and the relay node 2 as shown in the figure. on.
  • both the relay node 1 and the relay node 2 directly transmit the received header compressed data packet sent from the UE to the eNodeB.
  • the data packet sent by the UE to the relay node 1 is subjected to header compression by the UE in the IP/UDP/App. header, and is directly sent by the relay node 1 to the relay node 2; the relay node 1 is simultaneously
  • the IP/UDP/GTP-U header is encapsulated in the data packet, and the header compression profile of the IP/UDP/GTP-U header is compressed.
  • the relay node 2 will receive the compressed data packet sent from the relay node 1, and decompress the compressed IP/UDP/GTP-U header; encapsulate the IP/UDP/GTP-U in the IP packet sent to the eNodeB.
  • the header is compressed and the header compression profile of the IP/UDP/GTP-U header is performed.
  • the eNodeB entity will receive the compressed data packet sent from the relay node 2, encapsulate the compressed IP/UDP/App. header, and the IP/UDP/GTP-U header compressed by the relay node 2.
  • the eNodeB entity will decompress the IP/UDP/App. header compressed by the UE and the IP/UDP/GTP-U header compressed by the relay node 2, and send the packet to the next entity.
  • an IP/UDP/GTP-U header compression context relationship is established between the UE and the eNodeB entity that has been forwarded by the plurality of relay nodes; an IP is established between the relay node 1 and the relay node 2 /UDP/GTP-U header compression context; IP/UDP/GTP-U header compression context is established between relay node 2 and eNodeB entity.
  • the frame structure of the compressed IP header transmitted at the UE and the relay node is as shown in Fig. 7b.
  • the frame structure of the compressed IP header that establishes a nested two-layer ROHC compressed context (Context) between the relay node 2 and the eNodeB entity is as shown in FIG. 7d; wherein the IP/UDP/App. header is a relay The node directly forwards the header compressed by the UE entity, and the IP/UDP/GTP-U header is the header encapsulated by the relay node.
  • FIG. 8 is a schematic diagram of another method for header compression in a network relay scenario according to an embodiment of the present invention.
  • a dotted shadow is used in the drawing to represent a compressed portion.
  • the data packets sent by the UE are sent to the eNodeB through the relay node 1 and the relay node 2.
  • both the relay node 1 and the relay node 2 directly transmit the received header compressed data packet sent from the UE to the eNodeB.
  • the data packet sent by the UE to the relay node 1 is subjected to header compression by the UE in the IP/UDP/App. header, and after the intermediate entity 1 receives the data packet, the compressed IP/UDP/App is compressed.
  • the header is decompressed; the relay node 1 encapsulates the IP/UDP/GTP-U header in the data packet, and the relay node compresses the IP/UDP/App. header and the IP/UDP/GTP-U header respectively, and sends the packet to the packet header.
  • Relay node 2 Relay node 2.
  • the relay node 2 will receive the compressed data packet sent from the relay node 1, and decompress the compressed IP/UDP/App. header and the IP/UDP/GTP-U header respectively; the IP packet sent to the eNodeB Encapsulate the IP/UDP/GTP-U header and perform compression of the header compression profile of the IP/UDP/App. header and the IP/UDP/GTP-U header respectively.
  • the eNodeB entity will receive the compressed data packet sent from the relay node 2, encapsulate the compressed IP/UDP/App. header, and the IP/UDP/GTP-U header compressed by the relay node 2.
  • the eNodeB entity will decompress the IP/UDP/App. header compressed by the UE and the IP/UDP/GTP-U header compressed by the relay node 2, and send the packet to the next entity.
  • IP/UDP/GTP-U header compression is established between the UE and the relay node 1.
  • a TP/UDP/GTP-U header compression context relationship is established between the relay node 1 and the relay node 2
  • an IP/UDP/GTP-U header compression context relationship is established between the relay node 2 and the eNodeB entity
  • An IP/UDP/GTP-U header compression context relationship is established between the relay node 1 and the relay node 2
  • an IP/UDP/GTP-U header compression context relationship is established between the relay node 2 and the eNodeB entity.
  • the frame structure of the compressed IP header transmitted at the UE and the relay node is as shown in Fig. 7b.
  • the frame structure of the compressed IP header that establishes a nested two-layer ROHC compressed context (Context) between the relay node 1 and the relay node 2 is as shown in FIG. 7c; wherein, the IP/UDP/App. header is The relay node directly forwards the header compressed by the UE entity, and the IP/UDP/GTP-U header is the header encapsulated by the relay node.
  • the frame structure of the compressed IP header that establishes a nested two-layer ROHC compressed context (Context) between the relay node 2 and the eNodeB entity is as shown in FIG. 7d; wherein the IP/UDP/App. header is a relay
  • the node directly forwards the header compressed by the UE entity, and the IP/UDP/GTP-U header is the header encapsulated by the relay node.
  • the GTP tunnel user plane data packet defined by 3GPP includes the following information:
  • the monotonic sequence increases the change parameter, and the other parameters are Invariant parameters during GTP-U packet transmission.
  • the invariant parameters are saved on the compressor and the decompressor, ie the information used for compression and decompression; the corresponding parameters are encapsulated in the compressed GTP-U header.
  • the UDP protocol is used for the 7-bit GTP-U protocol header.
  • the frame structure of the UDP packet is shown in Figure 9a.
  • the Source Port and the Destination Port are parameters that are unchanged when transmitting multiple data packets, and can be saved as a state in the compressor and the decompressor that execute the compression algorithm.
  • the frame structure of the IPv4 header is shown in Figure 9b, where Version, Type of Service, Source Address, Destination Address, Offset are parameters that are invariant when transmitting multiple packets, and can be compressed and decompressed in the compression algorithm. It is saved as a state.
  • the frame structure of the IPv6 header is shown in Figure 9c, where the static header of the IPv6 packet includes version (version), Flow Label (stream label), Source Address (destination address), and destination address (dynamic address). Includes Traffic Classes, Hop Limit, Next Header, Payload Length.
  • version version
  • Flow Label stream label
  • Source Address destination address
  • dynamic address dynamic address
  • the static part of the header field of the above IP header can be compressed as a basic compression method of a header compression algorithm (for example, ROHC compression).
  • a header compression algorithm for example, ROHC compression
  • the compression algorithm includes other optimization methods, such as predicting the header content method, which can compress some non-static headers.
  • the relay node is still required to process the compressed packet header packet sent from the UE.
  • the packet header compression of the data packet between the relay node and the eNodeB entity Faced with the problem of saving the air interface bandwidth between the relay node and the eNodeB, the packet header compression of the data packet between the relay node and the eNodeB entity.
  • the air interface transmission protocol between the relay entity and the eNodeB uses different protocol stacks, and the two air ports use different respective header compressions, and need to coordinate the nesting of the respective compression algorithms and maintain the between the compressor and the decompressor. Context.
  • the method provided by the foregoing embodiment of the present invention effectively solves the problem that the IP packet occupies excessive bandwidth in the network relay scenario, and solves and implements the compressed IP by applying the ROHC compression mechanism on the RN, the eNB, and the UE. Header domain function, reducing air interface bandwidth usage and improving spectrum utilization.
  • FIG. 10 is a schematic diagram of a relay node according to an embodiment of the present invention, including:
  • the receiving unit 1001 is configured to receive a header-compressed first data packet sent by the user equipment or another relay node;
  • the encapsulating and compressing unit 1002 is configured to encapsulate a transport protocol header of the first data packet, and perform header compression on the foregoing packet header to form a second data packet.
  • the sending unit 1003 is configured to send the foregoing second data packet to the base station or the next relay node.
  • the above encapsulation unit 1002 is specifically configured to:
  • IP/UDP/APP After decompressing the header of the first data packet, compressing the header of the decompressed first data packet by using IP/UDP/APP. compression algorithm and IP/UDP/GTP-U compression algorithm respectively, respectively forming two The second data packet of the segment compression header; or, the IP/UDP/APP. and IP/UDP/GTP-U headers are compressed in a compressed header to form the second data packet.
  • the IP/UDP/GTP-U header is encapsulated outside the IP UDP/APP. header of the first header compressed packet to form the second data packet.
  • the relay node provided in this embodiment can implement the functions of the relay node in all the foregoing method embodiments of the present invention, and further implement the method provided in the embodiment.
  • the ROHC compression mechanism is applied to the R and the eNB and the UE to solve and implement the compressed IP header domain function, thereby reducing the air interface bandwidth occupation and improving the spectrum utilization.
  • the functional units in the various embodiments of the present invention may be integrated into one processing module, or each unit may exist physically separately, or two or more units may be integrated into one module.
  • the above integrated modules can be implemented in the form of hardware or in the form of software functional modules.
  • Above set A module that is implemented in the form of a software functional module and sold or used as a stand-alone product can also be stored in a computer readable storage medium.
  • 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 Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

网络中继场景下的头压缩方法及装置 本申请要求于 2009 年 8 月 26 日提交中国专利局、 申请号为 200910189676.9、 发明名称为"网络中继场景下的头压缩方法及装置"的中国专 利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域 本发明涉及移动通信领域， 尤其涉及一种网络中继场景下的头压缩方法及 装置。
背景技术
Relay (中继）技术是在原有站点的基础上， 通过增加一些新的 Relay站 (或 称中继节点， RN )加大站点和天线的分布密度。 这些新增 relay节点和原有基站 (母基站)都通过无线连接， 和传输网络之间没有有线的连接， 下行数据先到达 母基站， 然后再传给中继节点， 中继节点再传输至终端用户， 上行则反之。 这 种方法拉近了天线和终端用户的距离， 可以改善终端的链路质量， 从而提高系 统的频谱效率和用户数据率。
IPv6 采用了 128 比特的地址空间， 并且通过一些扩展头标获得了一套移 动 IPv6机制， 从而实现基于 IP ( Internet Protocol, 互联网协议）的设备在不同 的无线小区之间无缝移动。 但是， 另一方面大的地址空间和扩展头标增大了传 送开销。 特别是在无线链路的情况下，传送过长的头标会浪费很多本来就非常 紧张的无线链路带宽。 因此如何高效的传送 IPv6 分组成为移动 IP 中的一个必 须解决的关键问题。 一个解决的方案就是使用头标压缩技术， 以下将头标压 缩简称为头压缩。
发明人在实现本发明的过程中发现， 目前， 没有技术能够解决如何在网络 中继场景下进行头压缩。 发明内容
本发明实施例提供了一种网络中继场景下的头压缩方法及装置， 以使得在 网络中继场景下能够进行头压缩。
本发明实施例提供了一种网络中继场景下的头压缩方法， 包括：
中继节点接收用户设备或其它中继节点发送的经过头压缩的第一数据包， 对所述第一数据包封装传输协议包头， 并对所述包头进行头压缩， 形成第 二数据包；
将所述第二数据包发送给基站或者上行方向的下一中继节点。
本发明实施例还提供了一种网络中继场景下的头压缩方法， 包括
接收多个用户设备发送的经过头压缩的多个数据包后，
对所述多个数据包的包头使用同一传输协议包头进行封装， 并对所述传输 协议包头进行头压缩， 形成多个新的数据包；
将所述新的数据包发送给基站或者上行方向的下一中继节点。
本发明实施例提供了一种中继节点， 其特征在于， 包括：
接收单元， 用于接收用户设备或其它中继节点发送的经过头压缩的第一数 据包；
封装压缩单元， 用于对所述第一数据包封装传输协议包头， 并对所述包头 进行头压缩， 形成第二数据包；
发送单元， 用于将所述第二数据包发送给基站或者上行方向的下一中继节 点。
通过比较可以发现， 上述技术方案中的一个技术方案与现有技术相比， 具 有如下优点或有益效果：
本发明实施例中 , 中继节点通过接收用户设备或其它中继节点发送的经过 头压缩的第一数据包；对第一数据包封装传输协议包头，并对包头进行头压缩， 形成第二数据包； 将第二数据包发送给基站或者上行方向的下一中继节点； 从 而解决和实现头压缩功能， 减少了空口带宽占用， 提高了频谱利用率。 附图说明 图 1所示为本发明实施例提供的一种网络中继场景下的头压缩方法流程图； 图 2所示为典型的 Relay场景下的中继节点和 Donor eNobeB的用户面协议 栈架构图；
图 3a所示为本发明实施例提供的一种网络中继场景下的头压缩方法示意 图；
图 3b所示为图 3a对应实施例中在 UE和中继节点之间压缩的 IP包头的帧结 构；
图 3c所示为图 3a对应实施例中在中继节点和 eNodeB之间压缩的 IP包头的 帧结构；
图 3d所示为图 3a对应实施例中所需要的压缩参数配置过程示意图； 图 4a所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示 意图；
图 4b所示为图 4a对应实施例中在 UE和中继节点之间压缩的 IP包头的帧结 构；
图 4c所示为图 4a对应实施例中在中继节点和 eNodeB之间压缩的 IP包头的 帧结构；
图 4d所示为图 4a对应实施例中所需压缩参数的一种配置过程示意图； 图 4e所示为图 4a对应实施例中所需压缩参数的另一种配置过程示意图； 图 5a所示为本发明实施例提供的又一种网络中继场景下的头压缩方法示 意图；
图 5b所示为图 5a对应实施例中在 UE和中继节点之间压缩的 IP包头的帧结 构；
图 5c所示为图 5a对应实施例中在中继节点和 eNodeB之间压缩的 IP包头的 帧结构；
图 5d所示为图 5a对应实施例中所需要的压缩参数配置过程示意图； 图 6a所示为本发明实施例提供的又一种网络中继场景下的头压缩方法示 意图；
图 6b所示为图 6a对应实施例中在 UE和中继节点之间压缩的 IP包头的帧结 构；
图 6c所示为图 6a对应实施例中在中继节点和 eNodeB之间压缩的 IP包头的 帧结构；
图 7a所示为本发明实施例提供的又一种网络中继场景下的头压缩方法示 意图；
图 7b所示为图 7a对应实施例中在 UE和中继节点 1之间压缩的 IP包头的帧结 构；
图 7c所示为图 7a对应实施例中在中继节点 1和中继节点 2之间压缩的 IP包头 的帧结构；
图 7d所示为图 7a对应实施例中在中继节点 2和 eNodeB之间压缩的 IP包头的 帧结构；
图 8所示为本发明实施例提供的又一种网络中继场景下的头压缩方法示意 图；
图 9a所示为 UDP包的帧结构示意图；
图 9b所示为 IPv4的帧结构示意图；
图 9c所示为 IPv6的帧结构示意图；
图 10所示为本发明实施例提供的一种中继节点的结构示意图。 具体实施方式 为使本发明实施例的目的、 技术方案和优点更加清楚， 下面结合附图对本 发明各实施例作进一步的详细描述。
图 1 所示为本发明实施例提供的一种网络中继场景下的头压缩方法流程 图， 包括： 101、 接收用户设备或其它中继节点发送的经过头压缩的第一数据包 ,
102、 对上述第一数据包封装传输协议包头， 并对所述包头进行头压缩， 形成第二数据包；
上述传输协议， 具体包括： 隧道协议及隧道协议的传输协议； 其中， 隧道 协议包括： GTP-U ( GPRS Tunneling Protocol - User plane,通用分组无线服务 技术隧道协议 -用户面） ； IP/UDP ( User Datagram Protocol, 用户数据报协议） 协议包头用于被封装于 GTP-U隧道协议 , 其中 IP协议和 UDP协议用于承载隧道 协议。
步驟 102的具体执行方式可以是：
对上述第一数据包的包头进行解压缩后， 分别使用 IP/UDP/APP.压缩算法 和 IP/UDP/GTP-U压缩算法对解压后的第一数据包的包头进行压缩， 分别形成 具有两段压缩包头的第二数据包； 或者 , 将 IP/UDP/APP.和 IP/UDP/GTP-U包 头压缩在一段被压缩的包头中， 形成所述第二数据包。
或者可以是： 在所述经过头压缩的第一数据包的 IP/UDP/APP.包头外封装 IP/UDP/GTP-U包头， 形成所述第二数据包。
103、 将上述第二数据包发送给基站或者下一中继节点。
通过本实施例提供的方法， 在 UE和网络之间存在中继节点， 中继节点和 网络之间仍然为无线接口的情况下 , 中继节点分别进行和 UE之间的数据包的 包头压缩， 和中继节点及 eNodeB实体之间的数据包的包头压缩。 解决了在网 络中继场景下， 数据包占用过多带宽的问题， 通过在 RN和 eNB及 UE上应用 头压缩， 减少空口带宽占用， 提高频谱利用率。 下面将结合一种具体的 Relay场景对本发明实施例提供的方法进行介绍。 需要特别说明的是， 本发明实施例也可应用于其它 Relay场景中。 如图 2所示， 为典型的 Relay场景下的中继节点和 Donor eNobeB的用户面协 议栈架构， 涉及： App. (应用协议）， TCP ( Transfer Control Protocol, 传输控 制协议） , UDP, PDCP ( Packet Data Convergence Protocol , 分组数据汇聚协 议） , RLC ( Radio Link Control, 无线链路控制协议） , MAC ( Media Access Control, 媒介接入控制） , PHY ( Physical layer, 物理层） , GTP-U等， 其中 App. (应用协议）具体包括： RTP ( Realtime Transport Protocol, 实时传输协 议）， HTTP( Hypertext Transfer Protocol,超文本传输协议），或 FTP( File Transport Protocol, 文件传输协议）等。 在本发明中 IP/UDP/APP.代表一种应用协议和其 传输协议的组合形式，在本发明中还存在其他应用协议和 IP协议以及 TCP协议、 UDP协议的组合， 对本发明的内容同样适用。 图 3a所示为本发明实施例提供的一种网络中继 （Relay )场景下的头压缩 方法示意图； 为了清楚区分压缩部分与解压部分， 附图中使用点状阴影代表压 缩部分。 CID代表上下文标识（Context Identifier )， 由于在一个 载中可以维 护多个上下文， 因此需要针对一个媒体流使用上下文标识区分不同的头压缩过 程。 其中， 在 ROHC协议中 CID是一个从 0 - 15位的二进制数。 在本发明实 施例中， CID X代表 , 在 UE和中继节点间建立用 Context Identifier为 X标识 的 IP/UDP/APP.包头头压缩上下文； CID X，代表在中继节点到 eNodeB之间建 立用 Context Identifier为 X，标识的 IP/UDP/APP.包头头压缩上下文； CID Y代 表在在中继节点到 eNodeB 之间建立用 Context Identifier 为 Y 标识的 IP/UDP/GTP-U包头头压缩上下文。 CID X、 CID X，、 CID Y分别代表不同的上 下文标识。
在本实施例中， UE ( User Equipment, 用户设备）发送的媒体在用户面使 用头压缩算法进行了压缩， 在中继节点上被解开。 在中继节点， 发送给施主基 站（ Doner eNodeB )实体的用户面数据被分别使用 IP/UDP/APP.压缩 profile (算 法）和 IP/UDP/GTP-U压缩 profile分别压缩， eNodeB实体解开 IP包头， 并将 解压后的数据包发送给下一个网络实体，如：服务网关（Serving GATEWAY ) , 或公用数据网网关（ PDN GATEWAY )等。 其中， IP/UDP/APP.代表 UE正在 使用的业务从 TP协议到应用层协议间使用的协议栈， 例如 TP/UDP/RTP; 协 议栈是一些协议固定组合， 例如 IP/TCP/HTTP, IP/TCP, IP,UDP等， 该表达方 式在本发明其它实施例中的含义与上述相同 , 不再赘述。 上述 Doner eNodeB 是一个为 Relay节点提供信号的主基站， 以下简称为 eNodeB。
在本实施例中， UE 和中继节点之间建立压缩 IP/UDP/APP.包头的压缩 profile的上下文关系（ Context ) , 中继节点和 eNodeB之间建立 IP/UDP/GTP-U 包头的压缩 profile上下文关系。
在 UE和中继节点之间建立 ROHC压缩（ compressing )的上下文关系的压 缩的 IP包头的帧结构如图 3b所示。
在中继节点和 eNodeB 之间建立嵌套的两层 ROHC 压缩的上下文关系
( Context ) 的压缩的 IP包头的帧结构如图 3c所示。
图 3d所示为本实施例所述压缩过程中， 所需要的压缩参数配置过程， 或 称为协商过程，涉及 RRC( Radio Resource Control,无线资源控制协议）， S1-AP ( S1接口）， SCTP( Stream Control Transmission Protocol,串流控制传输协议 ) , NAS ( Non Access Stratum, 非接入层）。 此时的中继节点充当终端的行为， 也 可以使用 S1-AP接口， 协商头压缩参数， 具体包括：
301、 UE发送建立 DRB ( Dedicate Radio Bearer, 专用空口承载）配置中 包括 ROHC 参数 ( arameters ) , 此时发送的 ROHC 参数包括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile (算法） , 如 IP/UDP/APP.. 此时， UE 所支持的 ROHC压缩的 profile为单独 IP/UDP/App.压缩 profile, IP/TCP , IP/UDP 等压缩 profile。 PDCP参数代表 UE支持头压缩的能力。 其中， 所压缩包头的 profile, 指压缩机制对某一类包头组合的压缩算法。 图 3d中， prf.03 (算法 03 ) 代表一种所进行包头压缩的固定压缩算法的标识，例如 UE发出的 ROHC参数 中包括 Profile (算法） 0x0001 , 即代表 UE请求在所建立的 DRB 上进行支持 Profile 0x0001的 ROHC压缩。
302、 中继节点收到 UE发送的 ROHC参数， 如 ROHC压缩， 和所压缩包 头的 profile后，可以向 UE发送重配置， 网络重配置中包括 PDCP参数， PDCP 参数包括 DRB重配置的 DRB支持的 ROHC压缩参数和所压缩包头的 profile。 所压缩的 IP包头的帧结构如图 3b所示。
需要说明的是， 302步骤可以出现在步骤 301后， 也可以在流程中中继节 点完成 303步驟后执行。
此过程可以在 UE 和中继节点之间建立 ROHC 压缩的上下文关系 ( Context ) 。
303、 中继节点为了和 eNodeB实体的空中接口之间执行头压缩机制，在中 继节点和 eNodeB之间发送的用户面数据， 除了负载（payload ) , LI header ( Layer 1 header, 层 1包头)和； L2 header ( Layer2 header, 层 2包头) , 以及 如图中所示的 IP/UDP/APP.包头外， 用户面还包括 IP/UDP/GTP-U包头。 在本 实施例中，除了中继节点收到的 IP/UDP/APP.包头夕卜，还要压缩 IP/UDP/GTP-U 包头。
中继节点向 eNodeB发送支持的 ROHC参数， 此时发送的 ROHC参数包 括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile, 这里的压缩 profile分 别包括 IP/UDP/GTP-U压缩 profile标识和 IP/UDP/APP.压缩 rofile支持，表示 中继节点支持并请求在所请求的 DRB 中分别应用 IP/UDP/GTP-U 压缩和 IP/UDP/APP.压缩。
304、 eNodeB 收到了 ROHC 参数后， ROHC 压缩， 和所压缩包头的 IP/UDP/GTP-U压缩 profile标识和 IP/UDP/APP.压缩 profile , 可以向中继节点 发送重配置， 网络重配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压缩参数和所压缩包头的 IP/UDP/GTP-U压缩 profile标识 和 IP/UDP/APP.压缩 profile。 所压缩的 IP包头的帧结构如图 3c所示：
此过程可以在 eNodeB和中继节点之间建立嵌套的两层 ROHC压缩的上下 文关系 （Context ) 。
在此实施例中， 由于中继节点的存在， UE和 eNodeB 实体之间传输通过 两次空口传输，两层嵌套的 ROHC压缩可以解决在不同协议栈的头压缩机制问 题， 节约两段空口资源， 减少空口负载， 提高频谱利用率。 图 4a所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示 意图；为了清楚区分压缩部分与解压部分，附图中使用点状阴影代表压缩部分。
在本实施例中， UE发送的媒体在用户面使用 IP/UDP/App.包头压缩算法进 行了压缩， 中继节点不解开被压缩的 IP/UDP/App.包头， 将被压缩的 IP/UDP/App.包头发送给 eNodeB实体。
中继节点收到被压缩的数据包， 在包头外封装 IP/UDP/GTP-U包头， 可以 IP/UDP/GTP-U包头进行头压缩，发送给 eNodeB实体。 eNodeB实体将收到 的被分别压缩的 IP UDP/GTP-U包头和 IP/UDP/App.包头分别解压， 并发送给 下一个网络实体。
在此实施例中， UE和中继节点之间不建立压缩上下文关系； 在中继节点 和 eNodeB之间建立 IP/UDP/GTP-U包头的压缩 profile上下文关系； 在 UE和 eNodeB之间建立 IP UDP/App.包头的压缩 profile上下文关系。
在 UE和中继节点传输的压缩的 IP包头的帧结构如图 4b所示， 此帧结构 的 IP包的被压缩的 IP UDP/App.包头和 Payload (负载）部分被中继节点直接 发送给 eNodeB实体。
在中继节点和 eNodeB 之间建立嵌套的两层 ROHC 压缩的上下文关系 ( Context ) 的压缩的 IP包头的帧结构如图 4c所示， 其中， IP/UDP/App.包头 为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节点 封装的包头。
在上实施例中的压缩过程中 , UE和 eNodeB之间建立 ROHC压缩的支持 IP/UDP/APP.压缩 profile 的上下文关系， 中继节点将收到的 ROHC压缩后的 IP/UDP/APP.压缩包头， 直接发送给 eNodeB 实体， eNodeB 实体负责解开 IP/UDP/APP.压缩包头； 与此同时， 中继节点在发送给 eNodeB的数据包中，加 入了 TP/UDP/GTP-U包头， 并执行了 TP/UDP/GTP-U压缩 profHe。
图 4d所示为本实施例所述压缩过程中， 所需要的压缩参数配置过程的一 种情况， 具体包括：
401d、 UE发送建立 DRB配置中包括 ROHC参数， 此时发送的 ROHC参 数包括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile, 如 IP/UDP/APP.。 此时， UE所支持的 ROHC压缩的 profile为单独 IP/UDP/APP.压缩 profile, IP/TCP, IP/UDP等压缩 profile。 PDCP参数代表 UE支持头压缩的能力。其中， 所压缩包头的 profile, 指压缩机制对某一类包头组合的压缩算法。
402d、 中继节点收到 UE发送的 ROHC参数， 如 ROHC压缩， 和所压缩 包头的 profile后。 中继节点为了和 eNodeB实体的空中接口之间执行头压缩机 制，将收到的 ROHC参数发送给 eNodeB实体， ROHC参数 UE所请求的 DRB 支持的 ROHC压缩参数和所压缩包头的 profile。
中继节点为了和 eNodeB实体的空中接口之间执行头压缩机制， 在中继节 点和 eNodeB之间发送的用户面数据， 除了负载（ payload ) , Layer 1和 Layer 2 包头， 和中继节点收到的压缩状态中的 IP/UDP/APP.包头外， 用户面还包括 IP/UDP/GTP-U包头。 在本实施例中， 还要压缩 IP/UDP/GTP-U包头。
中继节点向 eNodeB 发送支持的 ROHC 参数包括 IP/UDP/GTP-U 压缩 profile 标识， 表示中继节点支持并请求在所请求的 DRB 中分别应用 IP/UDP/GTP-U压缩和 UE请求的 IP/UDP/APP.压缩。
403d、 eNodeB 收到了 ROHC 参数后， ROHC 压缩， 和所压缩包头的
IP/UDP/GTP-U压缩 profile标识和 IP/UDP/APP.压缩 profile, 可以向中继节点 发送重配置， 网络重配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压缩参数和所压缩包头的 IP/UDP/GTP-U压缩 profile标识 和 IP/UDP/APP.压缩 profile。
404d、 中继节点向 UE发送 PDCP参数， 可以向 UE发送重配置， 网络重 配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压 缩参数和所压缩包头的 profHe。 所压缩的 TP包头的帧结构如图 4c所示。
此过程可以在 UE以及中继节点和 eNodeB之间建立嵌套的两层 ROHC压 缩的上下文关系 （Context ) 。
图 4e所示为本实施例所述压缩过程中， 所需要的压缩参数配置过程的另 一种情况， 具体包括：
401e、 UE发送建立 DRB配置中包括 ROHC参数， 此时发送的 ROHC参 数包括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile, 如 IP/UDP/APP.。 此时， UE所支持的 ROHC压缩的 profile为单独 IP/UDP/APP.压缩 profile, IP/TCP, IP/UDP等压缩 profile。 PDCP参数代表 UE支持头压缩的能力。其中， 所压缩包头的 profile, 指压缩机制对某一类包头组合的压缩算法。
402e、 中继节点向 UE发送 PDCP参数 , 可以向 UE发送重配置 , 网络重 配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压 缩参数和所压缩包头的 profile。 所压缩的 IP包头的帧结构如图 4c所示。
403e、 中继节点收到 UE发送的 ROHC参数， 如 ROHC压缩， 和所压缩 包头的 profile后， 可以用于中继节点和 eNodeB实体的空中接口之间执行头压 缩机制 , 将收到的从 UE发送的 ROHC参数发送给 eNodeB实体， ROHC参数 UE所请求的 DRB支持的 ROHC压缩参数和所压缩包头的 profile。
中继节点为了和 eNodeB实体的空中接口之间执行头压缩机制， 在中继节 点和 eNodeB之间发送的用户面数据， 除了负载（ payload ) , Layer 1和 Layer 2 包头， 和中继节点收到的压缩状态中的 IP/UDP/APP.包头外， 用户面还包括 IP/UDP/GTP-U包头。 在本实施例中， 还要压缩 IP/UDP/GTP-U包头。
中继节点在向 eNodeB 实体发送从 UE 收到的 ROHC 参数的同时， 向 eNodeB发送支持的 ROHC参数包括 IP/UDP/GTP-U压缩 profile标识， 表示中 继节点支持并请求在所请求的 DRB中分别应用 IP/UDP/GTP-U压缩和 UE请求 的 IP/UDP/APP.压缩。
404e、 eNodeB 收到了 ROHC 参数， 如 ROHC 压缩， 和所压缩包头的 TP/UDP/GTP-U压缩 profile标识和 TP/UDP/APP.压缩 profile后， 可以向中继节 点发送重配置， 网络重配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压缩参数和所压缩包头的 IP/UDP/GTP-U压缩 profile标识 和 IP/UDP/APP.压缩 profile。
此过程可以在 UE以及中继节点和 eNodeB之间建立嵌套的两层 ROHC压 缩的上下文关系 （Context ) 。
图 4a-4e对应实施例提供了中继节点进行头压缩的方法， 以及两种压缩参 数配置方法。 解决了在网络中继场景下， IP 包占用过多带宽的问题， 通过在 RN和 eNB及 UE上应用 ROHC压缩机制 , 解决和实现压缩 IP头域功能， 减 少了空口带宽占用， 提高频谱利用率。 图 5a所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示 意图；为了清楚区分压缩部分与解压部分，附图中使用点状阴影代表压缩部分。
在本实施例中， UE发送的媒体在用户面使用头压缩算法进行了压缩， 在 中继节点上被解开。 在中继节点发送给 eNodeB 实体的用户面数据使用 IP/UDP/APP.^ IP/UDP/GTP-U包头压缩 profile进行压缩， eNodeB实体解开 IP 包头， 并将解压后的数据包发送给下一个实体。
在本实施例中， UE 和中继节点之间建立压缩 IP/UDP/APP.包头的压缩 profile 的上下文关系； 在中继节点和 eNodeB 之间建立 IP/UDP/APP.和 IP/UDP/GTP-U包头的压缩 profile上下文关系。
在 UE和中继节点之间建立 ROHC压缩的上下文关系（ Context )的压缩的 IP包头的帧结构如图 5b所示。
在中继节点和 eNodeB 之间建立 ROHC 压缩的 IP/UDP/APP.和 IP/UDP/GTP-U 包头的上下文关系 （Context ) 的压缩的 IP 包头的帧结构如图 5c所示。
图 5d所示为本实施例所述压缩过程中， 所需要的压缩参数配置过程， 或 称为协商过程， 具体包括：
501、 UE发送建立 DRB配置中包括 ROHC参数， 此时发送的 ROHC参数 包括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile, 如 IP/UDP/APP.。 此 时，UE所支持的 ROHC压缩的 profile为单独 IP/UDP/App.压缩 profile , IP/TCP , IP/UDP等压缩 profile。 PDCP参数代表 UE支持头压缩的能力。 其中， 所压缩 包头的 profile, 指压缩机制对某一类包头組合的压缩算法。
502、 中继节点收到 UE发送的 ROHC参数， 如 ROHC压缩 , 和所压缩包 头的 profile后，可以向 UE发送重配置， 网络重配置中包括 PDCP参数， PDCP 参数包括 DRB重配置的 DRB支持的 ROHC压缩参数和所压缩包头的 profile。 所压缩的 IP包头的帧结构图 5b所示；
需要说明的是， 502步驟可以出现在步驟 501后， 也可以在流程中中继节 点完成 503步驟后执行
此过程可以在 UE 和中继节点之间建立 ROHC 压缩的上下文关系 ( Context ) 。
503、 中继节点为了和 eNodeB实体的空中接口之间执行头压缩机制，在中 继节点和 eNodeB之间发送的用户面数据， 除了负载（payload ) , Layer 1和 Layer 2 包头， 和如图中所示的 IP/UDP/APP.包头外， 用户面还包括 IP/UDP/GTP-U 包头。 在上实施例中， 除了中继节点收到的 IP/UDP/APP.包头 外， 还同时一起压缩 IP/UDP/GTP-U包头。
中继节点向 eNodeB发送支持的 ROHC参数， 此时发送的 ROHC参数包 括压缩机制， 如 ROHC压缩， 和所压缩包头的 profile, 这里的压缩 profile包 括压缩 IP/UDP/GTP-U和 IP/UDP/APP.包头的压缩 profile指示 , 表示中继节点 支持并请求在所请求的 DRB 中应用 IP/UDP/GTP-U 和 IP/UDP/APP.压缩 profile。
504、 eNodeB 收到了 ROHC 参数后， ROHC 压缩， 和所压缩包头的 IP/UDP/GTP-U和 IP/UDP/APP.压缩 profile, 可以向中继发送重配置， 网络重 配置中包括 PDCP参数， PDCP参数包括 DRB重配置的 DRB支持的 ROHC压 缩参数和所压缩包头的 IP/UDP/GTP-U、 IP/UDP/APP.压缩 profile。所压缩的 IP 包头的帧结构如图 5c所示；此过程可以在 eNodeB和中继节点之间建立嵌套的 两层 ROHC压缩的上下文关系 （Context ) 。 图 6a所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示 意图；为了清楚区分压缩部分与解压部分，附图中使用点状阴影代表压缩部分。
在本实施例中， 多个用户终端 UEs发送的数据在 UE和中继节点之间进行 IP/UDP/App.包头的头压缩。 中继节点向 eNodeB的数据将多个 UEs发送的 IP 包头使用同一个 IP/UDP/GTP-U包头进行封装， 并进行 IP/UDP/GTP-U包头的 头压缩 profile算法。
在本实施例中， 釆用了实施例 3 中的头压缩过程， 即中继节点将收到的 UE1和 UE2发送的 IP包直接向 eNodeB实体发送， 这时， UE和中继节点之间 不建立压缩上下文关系； 在中继节点和 eNodeB之间建立 IP/UDP/GTP-U包头 的压缩 profile上下文关系； 在 UE1及 UE2和 eNodeB之间建立 IP/UDP/App. 包头的压缩 profile上下文关系。 在 UE和中继节点传输的压缩的 IP包头的帧 结构如图 6b所示； 此帧结构的 IP包被中继节点直接发送给 eNodeB实体。
在中继节点和 eNodeB 之间建立嵌套的两层 ROHC 压缩的上下文关系 ( Context ) 的压缩的 IP包头的帧结构为如图 6c所示； 其中， IP/UDP/App.包 头为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节 点封装的包头。
eNodeB实体解开封装的 UE1和 UE2发送的数据包时， 使用 UE1和 UE2 所发送数据的标识区分数据包， 标识数据包的可以是 IP地址， 端口号， 用户 标识、 头压缩上下文标识等。
本实施例在实现时， 在 UE和中继节点之间还可以按照图 3所对应实施 例中说明的方法实现， 即在 UE发送的压缩后的 IP/UDP/App.包头， 在中继节 点上被解开； 然后在中继节点发送数据包时， 按照本实施例的压缩方式进行压 缩， 如图 6b、 6c的帧结构所示。 图 7a所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示 意图；为了清楚区分压缩部分与解压部分，附图中使用点状阴影代表压缩部分。
本实施例中， 在 UE和 eNodeB之间存在多个中继节点的情况， 在此情况 下， UE所发出的数据包经过了如图所示的中继节点 1 和中继节点 2发送到 eNodeB上。 在本实施中， 中继节点 1和中继节点 2都将收到的从 UE发送的 被头压缩的数据包， 直接发送到 eNodeB上。
在本实施例中， UE发送到中继节点 1的数据包被 UE进行了 IP/UDP/App. 包头的头压缩， 被中继节点 1直接发送到中继节点 2; 中继节点 1同时在数据 包中封装 IP/UDP/GTP-U包头， 并进行 IP/UDP/GTP-U包头的头压缩 profile的 压缩。
中继节点 2 将收到从中继节点 1 发送的压缩后的数据包， 将被压缩的 IP/UDP/GTP-U包头解压缩； 在发送给 eNodeB的 IP包中封装 IP/UDP/GTP-U 包头 , 并进行 IP/UDP/GTP-U包头的头压缩 profile的压缩。
eNodeB实体将收到的从中继节点 2发送的压缩后的数据包， 封装了压缩 后的 IP/UDP/App.包头， 和中继节点 2压缩的 IP/UDP/GTP-U包头。 eNodeB实 体将解压 UE压缩的 IP/UDP/App.包头和中继节点 2压缩的 IP/UDP/GTP-U包 头， 并将数据包发送给下一个实体。
在本实施例中， 在 UE和经过多个中继节点转发后的 eNodeB实体之间建 立 IP/UDP/GTP-U包头压缩上下文关系； 在中继节点 1和中继节点 2之间建立 了 IP/UDP/GTP-U包头压缩上下文关系； 在中继节点 2和 eNodeB实体之间建 立了 IP/UDP/GTP-U包头压缩上下文关系。 在 UE和中继节点传输的压缩的 IP 包头的帧结构如图 7b所示。
在中继节点 1和中继节点 2之间建立嵌套的两层 ROHC压缩的上下文关系 ( Context ) 的压缩的 TP包头的帧结构如图 7c所示； 其中， TP/UDP/App.包头 为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节点 封装的包头。
在中继节点 2和 eNodeB实体之间建立嵌套的两层 ROHC压缩的上下文关 系 （Context ) 的压缩的 IP包头的帧结构如图 7d所示； 其中， IP/UDP/App.包 头为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节 点封装的包头。
图 8所示为本发明实施例提供的另一种网络中继场景下的头压缩方法示意 图； 为了清楚区分压缩部分与解压部分， 附图中使用点状阴影代表压缩部分。
本实施例中， 在 UE和 eNodeB之间存在多个中继节点的情况， 在此情况 下， UE所发出的数据包经过了中继节点 1和中继节点 2发送到 eNodeB上。 在本实施中， 中继节点 1和中继节点 2都将收到的从 UE发送的被头压缩的数 据包， 直接发送到 eNodeB上。
在本实施例中， UE发送到中继节点 1的数据包被 UE进行了 IP/UDP/App. 包头的头压缩，在中间实体 1收到数据包后将压缩后的 IP/UDP/App.包头解压； 被中继节点 1 在数据包中封装 IP/UDP/GTP-U 包头， 中继节点分别压缩 IP/UDP/App.包头和 IP/UDP/GTP-U包头， 并将数据包发送给中继节点 2。
中继节点 2 将收到从中继节点 1 发送的压缩后的数据包， 将被压缩的 IP/UDP/App.包头和 IP/UDP/GTP-U包头分别解压缩； 在发送给 eNodeB的 IP 包中封装 IP/UDP/GTP-U 包头， 并进行分别进行 IP/UDP/App.包头和 IP/UDP/GTP-U包头的头压缩 profile的压缩。
eNodeB实体将收到的从中继节点 2发送的压缩后的数据包， 封装了压缩 后的 IP/UDP/App.包头， 和中继节点 2压缩的 IP/UDP/GTP-U包头。 eNodeB实 体将解压 UE压缩的 IP/UDP/App.包头和中继节点 2压缩的 IP/UDP/GTP-U包 头， 并将数据包发送给下一个实体。
在本实施例中， 在 UE和中继节点 1之间建立 IP/UDP/GTP-U包头压缩上 下文关系 , 中继节点 1和中继节点 2之间建立 TP/UDP/GTP-U包头压缩上下文 关系， 中继节点 2和 eNodeB实体之间建立 IP/UDP/GTP-U包头压缩上下文关 系； 在中继节点 1和中继节点 2之间建立了 IP/UDP/GTP-U包头压缩上下文关 系； 在中继节点 2和 eNodeB实体之间建立了 IP/UDP/GTP-U包头压缩上下文 关系。 在 UE和中继节点传输的压缩的 IP包头的帧结构如图 7b所示。
在中继节点 1和中继节点 2之间建立嵌套的两层 ROHC压缩的上下文关系 ( Context ) 的压缩的 IP包头的帧结构如图 7c所示； 其中， IP/UDP/App.包头 为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节点 封装的包头。
在中继节点 2和 eNodeB实体之间建立嵌套的两层 ROHC压缩的上下文关 系 （Context ) 的压缩的 IP包头的帧结构如图 7d所示； 其中， IP/UDP/App.包 头为中继节点直接转发由 UE实体压缩的包头， IP/UDP/GTP-U包头为中继节 点封装的包头。 下面介绍以上方法实施例中所涉及的 IP/UDP/GTP-U包头压缩算法， 具体 包括：
3GPP定义的 GTP隧道用户平面数据包， 封装的包头包括以下信息：
- GTP version ("001") GTP版本
- PT flag ("1") - protocol type协议类型
- Extension Header flag ( "1" ) 头 i或扩展标志
- Sequence Number flag ("1")序列标志
- Message Type ( "00000000" ) 消息类型
- N-PDU number flag ("1") - Network-Protocol Data Unit标志
- TEID ("00000000") 隧道标志
- Sequence Number ("000000001")序号
其中 Sequence Number 参数时单调序列增加变化参数， 其他参数为在 GTP-U数据包发送过程中不变的参数。 根据 ROHC压缩架构， 将不变的参数 在压缩器和解压器上保存状态， 即用于压缩和解压时的信息； 对应变化的参数 则将参数在压缩后的 GTP-U包头中进行封装。
UDP协议用于 7 载 GTP-U协议包头， UDP包的帧结构如图 9a所示。 其 中 , Source Port和 Destination Port为在传输多个数据包时不变的参数， 可以在 执行该压缩算法的压缩器和解压器中被作为状态保存。
IPv4包头的帧结构如图 9b所示， 其中， Version , Type of Service , Source Address, Destination Address, Offset是在传输多个数据包时不变的参数， 可以 在执行该压缩算法的压缩器和解压器中被作为状态保存。
IPv6包头的帧结构如图 9c所示，其中， IPv6数据包的静态包头包括 version (版本 ) , Flow Label (流标签 ) , Source Address (源地址 ) , Destination Address (目的地址）； 动态变化的地址包括 Traffic Classs (负载级别） ， Hop Limit (条数限制） ； Next Header (下一头） ； Payload Length (负载长度） 。 因而 在压缩 IPv6部分包头时， 静态部分可以作为包头被头压缩方法压缩的部分。
以上 IP包头的头域静态部分可以被作为头压缩算法（例如， ROHC压缩） 的基本压缩方法压缩。 对于非静态包头部分， 压缩算法包括其他优化方法， 例 如预测包头内容方法， 可以压缩部分非静态包头。 综上， 在 UE和网络之间存在中继节点， 中继节点和网络之间仍然为无线 接口的情况下， 中继节点除了能够处理从 UE发出的经过压缩的包头的数据包 外， 仍然需要面临节省中继节点和 eNodeB之间空口带宽的问题， 中继节点及 eNodeB实体之间的数据包的包头压缩。而在中继实体和 eNodeB之间的空口传 输协议使用不同的协议栈， 两段空口上使用不同各自的头压缩， 并且需要协调 各自的压缩算法的嵌套和维护压缩器和解压器之间的上下文关系。通过本发明 上述实施例提供的方法，有效解决了在网络中继场景下， IP包占用过多带宽的 问题， 通过在 RN和 eNB及 UE上应用 ROHC压缩机制， 解决和实现压缩 IP 头域功能， 减少空口带宽占用， 提高频谱利用率。
本领域普通技术人员可以理解， 上述各实施例中的全部或部分步骤可以通 过程序指令相关的硬件来实现， 上述的程序可以存储于计算机可读取存储介质 中， 上述的存储介质， 可以是 ROM/RAM、 磁碟、 光盘等。 图 10所示为本发明实施例提供的一种中继节点 , 包括：
接收单元 1001 , 用于接收用户设备或其它中继节点发送的经过头压缩的第 一数据包；
封装压缩单元 1002, 用于对上述第一数据包封装传输协议包头， 并对上述 包头进行头压缩， 形成第二数据包；
发送单元 1003 , 用于将上述第二数据包发送给基站或者下一中继节点。 上述封装单元 1002具体用于：
对上述第一数据包的包头进行解压缩后， 分别使用 IP/UDP/APP.压缩算法 和 IP/UDP/GTP-U压缩算法对解压后的第一数据包的包头进行压缩， 分别形成 具有两段压缩包头的第二数据包； 或者 , 将 IP/UDP/APP.和 IP/UDP/GTP-U包 头压缩在一段被压缩的包头中， 形成上述第二数据包。
或者， 在上述经过头压缩的第一数据包的 IP UDP/APP.包头外封装 IP/UDP/GTP-U包头， 形成上述第二数据包。
本实施例提供的中继节点 , 能够实现本发明上述所有方法实施例中中继节 点的功能， 进而实现实施例中提供的方法。 解决在网络中继场景下， IP包占用 过多带宽的问题， 通过在 R 和 eNB及 UE上应用 ROHC压缩机制 , 解决和 实现压缩 IP头域功能， 减少空口带宽占用， 提高频谱利用率。
需要特别说明的是， 以上全部或部分单元可以集成在芯片中实现。 在本发 明各个实施例中的各功能单元可以集成在一个处理模块中 , 也可以是各个单元 单独物理存在， 也可以两个或两个以上单元集成在一个模块中。 上述集成的模 块既可以采用硬件的形式实现， 也可以采用软件功能模块的形式实现。 上述集 成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时， 也 可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存 储器， 磁盘或光盘等。
附图和相关描述只是为了说明本发明的原理， 并非用于限定本发明的保护 范围。 例如， 本发明各实施例中的消息名称和实体可以根据网络的不同而有所 变化， 一些消息也可以省略。 因此， 凡在本发明的精神和原则之内所作的任何 修改、 等同替换、 改进等， 均包含在本发明的保护范围内。
虽然通过参照本发明的某些优选实施例， 已经对本发明进行了图示和描 述， 但本领域的普通技术人员应该明白， 可以在形式上和细节上对其作各种改 变， 而不偏离本发明的精神和范围。

Claims

权利要求
1、 一种网络中继场景下的头压缩方法， 其特征在于， 包括：
中继节点接收用户设备或其它中继节点发送的经过头压缩的第一数据 包；
对所述第一数据包封装传输协议包头， 并对所述包头进行头压缩， 形 成第二数据包；
将所述第二数据包发送给基站或者上行方向的下一中继节点。
2、 根据权利要求 1所述方法， 其特征在于， 所述封装传输协议包头使 用的传输协议包括： 隧道协议及隧道协议的传输协议； 其中， 所述隧道协 议包括： 通用分组无线服务技术隧道协议-用户面， 即 GTP-U。
3、 根据权利要求 1所述方法， 其特征在于， 所述对所述第一数据包封 装传输协议包头， 并对所述传输协议包头进行头压缩， 形成第二数据包， 具体包括：
对所述第一数据包的包头进行解压缩， 得到互联网协议 /用户数据报协 议 /应用协议 IP/UDP/APP. 包头 ,
使用互联网协议 /通用分组无线服务技术隧道协议-用户面 IP/UDP/ GTP-U包头对解压后的第一数据包进行封装；
使用 IP/UDP/APP.压缩算法对所述 IP/UDP/APP. 包头进行压缩 , 使用 IP/UDP/GTP-U压缩算法对所述 IP/UDP/GTP-U包头进行压缩 ,形成具有两段 压缩包头的第二数据包； 或者， 对所述 IP/UDP/APP.包头和 IP/UDP/GTP-U 包头进行压缩， 形成具有一段压缩包头的第二数据包。
4、 根据权利要求 3所述方法， 其特征在于， 还包括：
所述中继节点接收所述用户设备发送的对所述第一数据包使用的第一 鲁棒性 IP头压缩 ROHC参数；
所述中继节点向所述用户设备发送所述中继节点支持的第一分组数据 汇聚协议 PDCP参数， 所述第一 PDCP参数包括所述第一 ROHC参数； 所述对所述第一数据包的包头进行解压缩 , 具体包括：
所述中继节点根据所述第一 ROHC参数对所述第一数据包的包头进行 解压缩；
所述对所述第一数据包的包头进行解压缩后， 还包括：
所述中继节点将对所述第二数据包使用的第二 ROHC参数发送给所述 基站，以使得所述基站根据所述第二 ROHC参数对所述第二数据包的包头进 行解压缩，所述第二 ROHC参数包括所述中继节点对所述第二数据包的包头 进行压缩使用的算法；
所述中继节点接收所述基站发送的所述基站支持的第二 PDCP参数， 所 述第二 PDCP参数包括所述第二 ROHC参数。
5、 根据权利要求 4所述方法， 其特征在于，
在所述形成具有两段压缩包头的第二数据包的情况下 ,
所述第二 ROHC参数包括： IP/UDP/APP.压缩算法和 IP/UDP/GTP-U压缩 算法；
或者，
在所述形成具有一段压缩包头的第二数据包的情况下，
所述第二数据包使用的 ROHC参数包括： 所述 IP/UDP/APP. 包头和 IP/UDP/GTP-U包头对应的一个压缩算法。
6、 根据权利要求 1述方法， 其特征在于， 所述中继节点接收用户设备 发送的经过头压缩的第一数据包， 包括：
所述中继节点接收所述用户设备发送的封装了 IP/UDP/APP. 包头， 且 对所述 IP/UDP/APP. 包头进行头压缩后的第一数据包；
所述对所述第一数据包封装传输协议包头， 并对所述包头进行头压缩， 具体包括：
在所述经过头压缩的第一数据包的 IP/UDP/APP.包头外封装 TP/UDP/GTP-U包头 , 并对所述 TP/UDP/GTP-U包头进行头压缩。
7、 根据权利要求 6所述方法， 其特征在于， 还包括：
所述中继节点接收所述用户设备发送的对所述第一数据包使用的第三 ROHC参数；
所述中继节点将所述第三 ROHC参数转发给所述基站；
所述中继节点将对所述第二数据包使用的第四 ROHC参数发送给所述 基站 , 以使得所述基站根据所述三 ROHC参数和所述第四 ROHC参数对所述 第二数据包的包头进行解压缩，其中， 所述第四 ROHC参数包括所述中继节 点对所述第二数据包的包头进行压缩使用的算法；
所述中继节点接收所述基站发送的所述基站支持的 PDCP参数， 所述 PDCP参数包括所述第三 ROHC参数和所述第四 ROHC参数；
所述中继节点向所述用户设备转发所述基站支持的 PDCP参数。
8、 根据权利要求 6所述方法， 其特征在于， 还包括：
所述中继节点接收所述用户设备发送的对所述第一数据包使用的第五 ROHC参数；
所述中继节点向所述用户设备发送所述中继节点支持的第三 PDCP参 数， 所述第三 PDCP参数包括所述第五 ROHC参数；
所述中继节点将所述第五 ROHC参数转发给所述基站；
所述中继节点将对所述第二数据包使用的第六 ROHC参数发送给所述 基站 , 以使得所述基站根据所述第五 ROHC参数和所述第六 ROHC参数对所 述第二数据包的包头进行解压缩， 其中， 所述第六 ROHC参数包括所述中继 节点对所述第二数据包的包头进行压缩使用的算法；
所述中继节点接收所述基站发送的所述基站支持的第四 PDCP参数 , 所 述第四 PDCP参数包括所述第五 ROHC参数和所述第六 ROHC参数。
9、 根据权利要求 8所述方法， 其特征在于，
所述第五 ROHC参数包括： IP/UDP/APP.压缩算法； 所述第六 ROHC参 数包括： TP/UDP/GTP-U压缩算法。
10、 根据权利要求 1 所述方法， 其特征在于， 所述中继节点接收其它 中继节点发送的经过头压缩的第一数据包， 包括：
所述中继节点接收其它中继节点发送的封装了 IP/UDP/APR包头和 IP/UDP/GTP-U包头， 且对所述 IP/UDP/APP.包头和 IP/UDP/GTP-U包头进 行头压缩后的第一数据包；
所述对所述第一数据包封装传输协议包头 , 并对所述包头进行头压缩 , 形成第二数据包， 包括：
对所述第一数据包的 IP UDP/APP.包头和 IP/UDP/GTP-U包头进行解压 缩； 使用 IP/UDP/APP.压缩算法对所述 IP/UDP/APP. 包头进行压缩， 使用 IP/UDP/GTP-U压缩算法对所述 IP/UDP/GTP-U包头进行压缩 , 形成具有两 段压缩包头的第二数据包 ,或者 ,对所述 IP/UDP/APP.包头和 IP/UDP/GTP-U 包头进行压缩， 形成具有一段压缩包头的第二数据包；
或者，
对所述第一数据包的 IP/UDP/GTP-U 包头进行解压缩； 使用 IP/UDP/GTP-U压缩算法对所述 IP/UDP/GTP-U包头进行压缩 , 形成具有两 段压缩包头的第二数据包， 所述两段压缩包头包括： IP/UDP/APP. 包头和 IP/UDP/GTP-U包头。
11、 根据权利要求 1所述的方法， 其特征在于，
所述用户设备为多个用户设备；
所述中继节点接收用户设备发送的经过头压缩的第一数据包， 包括： 所述接收所述多个用户设备发送的经过头压缩的多个第一数据包； 所述对所述第一数据包封装传输协议包头， 并对所述包头进行头压缩， 形成第二数据包， 包括：
对所述多个第一数据包的包头使用同一传输协议包头进行封装， 并对 所述传输协议包头进行头压缩， 形成一个第二数据包。
12、 根据权力要求 11所述的方法， 其特征在于， 所述第二数据包中封 装有所述多个用户设备分别对应的 IP地址和 /或端口号，用于区分所述同一 个传输协议包头封装的来自多个用户设备发送的数据包。
13、 一种中继节点， 其特征在于， 包括：
接收单元， 用于接收用户设备或其它中继节点发送的经过头压缩的第 一数据包；
封装压缩单元， 用于对所述接收单元接收的所述第一数据包封装传输 协议包头， 并对所述包头进行头压缩， 形成第二数据包；
发送单元， 用于将所述封装压缩单元封装得到的所述第二数据包发送 给基站或者上行方向的下一中继节点。
14、 根据权利要求 13所述中继节点， 其特征在于， 所述封装单元具体 用于：
对所述第一数据包的包头进行解压缩， 得到互联网协议 /用户数据报协 议 /应用协议 IP/UDP/APP. 包头，
使用互联网协议 /通用分组无线服务技术隧道协议-用户面 IP/UDP/GTP-U包头对解压后的第一数据包的包头进行封装；
使用 IP/UDP/APP.压缩算法对所述 IP/UDP/APP. 包头进行压缩， 使用 IP/UDP/GTP-U压缩算法对所述 IP/UDP/GTP-U包头进行压缩 ,形成具有两段 压缩包头的第二数据包； 或者， 对所述 IP/UDP/APP.包头和 IP/UDP/GTP-U 包头进行压缩， 形成具有一段压缩包头的第二数据包。
15、 根据权利要求 13所述中继节点， 其特征在于， 所述封装单元具体 用于：
在所述经过头压缩的第一数据包的 IP/UDP/APP.包头外封装 IP/UDP/GTP-U包头， 形成所述第二数据包， 并对所述 IP/UDP/GTP-U包头 进行头压缩。
PCT/CN2010/076396 2009-08-26 2010-08-26 网络中继场景下的头压缩方法及装置 WO2011023124A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES10811284.8T ES2489469T3 (es) 2009-08-26 2010-08-26 Método y aparato para compresión de cabecera en escenarios operativos de relé de red
EP10811284.8A EP2464063B1 (en) 2009-08-26 2010-08-26 Method and apparatus for header compression in network relay scenarios
US13/405,032 US20120155375A1 (en) 2009-08-26 2012-02-24 Method and Apparatus for Header Compression in Network Relay Scenario

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2009101896769A CN101998511B (zh) 2009-08-26 2009-08-26 网络中继场景下的头压缩方法及装置
CN200910189676.9 2009-08-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/405,032 Continuation US20120155375A1 (en) 2009-08-26 2012-02-24 Method and Apparatus for Header Compression in Network Relay Scenario

Publications (1)

Publication Number Publication Date
WO2011023124A1 true WO2011023124A1 (zh) 2011-03-03

Family

ID=43627278

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/076396 WO2011023124A1 (zh) 2009-08-26 2010-08-26 网络中继场景下的头压缩方法及装置

Country Status (5)

Country Link
US (1) US20120155375A1 (zh)
EP (1) EP2464063B1 (zh)
CN (1) CN101998511B (zh)
ES (1) ES2489469T3 (zh)
WO (1) WO2011023124A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017035752A1 (zh) * 2015-08-31 2017-03-09 华为技术有限公司 一种数据流报头压缩传输方法、系统及控制器、节点

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8902805B2 (en) * 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing
CN113301014B (zh) 2011-12-20 2022-09-23 华为技术有限公司 网际协议头置换映射关系的获取方法及网络节点
ES2441140B1 (es) * 2012-07-30 2015-03-10 Vodafone Espana Sau Metodo, entidad de red y equipo de usuario para entregar informacion a una red de acceso de radio.
WO2014031689A1 (en) 2012-08-24 2014-02-27 Oceus Networks Inc. Mobile cellular networks
WO2014031597A1 (en) 2012-08-24 2014-02-27 Oceus Networks Inc. Mobile cellular networks
WO2014101062A1 (zh) 2012-12-27 2014-07-03 华为技术有限公司 用户面数据传输方法、移动管理网元、演进型基站及系统
CN103973645B (zh) * 2013-01-30 2017-11-24 华为技术有限公司 一种数据传输方法和相关装置
WO2014179235A1 (en) * 2013-04-29 2014-11-06 Oceus Networks Inc. Mobile cellular network backhaul
JP6056640B2 (ja) * 2013-05-07 2017-01-11 富士通株式会社 通信装置，管理装置，処理方法，および処理プログラム
WO2016067954A1 (ja) * 2014-10-30 2016-05-06 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
US10142840B2 (en) * 2015-01-29 2018-11-27 Motorola Mobility Llc Method and apparatus for operating a user client wireless communication device on a wireless wide area network
CN106302245A (zh) * 2015-06-08 2017-01-04 中国移动通信集团公司 一种lte系统中数据包的压缩方法和装置
EP3393168B1 (en) * 2015-12-15 2021-08-04 LG Electronics Inc. User equipment and data reception method, and network node and data transmission method
US9986456B2 (en) 2016-06-03 2018-05-29 Futurewei Technologies, Inc. System and method for data forwarding in a communications system
US10873891B2 (en) 2016-07-06 2020-12-22 Oceus Networks, Llc Secure network rollover
US9686238B1 (en) 2016-07-07 2017-06-20 Oceus Networks Inc. Secure network enrollment
US9924427B2 (en) 2016-07-07 2018-03-20 Oceus Networks Inc. Network backhaul access
EP3598793A4 (en) * 2017-03-14 2020-09-23 NTT DoCoMo, Inc. WIRELESS COMMUNICATION DEVICE AND WIRELESS COMMUNICATION METHOD
US10172078B2 (en) 2017-03-31 2019-01-01 Oceus Networks Inc. Targeted user equipment-base station communication link
US10205802B2 (en) * 2017-06-01 2019-02-12 Institute For Information Industry Transmission system and transmission method
US11246031B2 (en) 2018-08-15 2022-02-08 Oceus Networks, Llc Disguising UE communications in a cellular network
US11038990B2 (en) * 2018-12-28 2021-06-15 Intel Corporation Methods and apparatus to compress packets in a computing environment
US11973822B2 (en) * 2021-03-05 2024-04-30 Parallel Wireless, Inc. Method for handling of an inbound SCTP packet at an SCTP load balancer and tunneling methodology
CN117998676A (zh) * 2023-10-11 2024-05-07 腾讯科技（深圳）有限公司 基于多通道的数据传输方法、终端设备以及目标网关

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1377549A (zh) * 1999-09-29 2002-10-30 艾利森电话股份有限公司 一种支持压缩分段头标的分段协议
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信系统
CN101369977A (zh) * 2008-09-18 2009-02-18 华为技术有限公司 数据传输的方法、装置和系统
WO2009099845A2 (en) * 2008-01-30 2009-08-13 Qualcomm Incorporated Relay based header compression

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7209491B2 (en) * 2002-06-28 2007-04-24 Nokia Corporation Method and system for transmitting data in a packet based communication network
US7701981B2 (en) * 2005-10-27 2010-04-20 Qualcomm Incorporated System and method for improving robust header compression (ROHC) efficiency
US8199663B2 (en) * 2007-09-28 2012-06-12 Qualcomm Incorporated Robust header compression/decompression methods and systems
CN101159667B (zh) * 2007-10-16 2010-09-01 中兴通讯股份有限公司 用于移动多媒体广播系统对分组数据进行报头压缩的方法
KR101021059B1 (ko) * 2007-11-07 2011-03-15 삼성전자주식회사 광대역 무선접속 시스템의 연결 수락 제어 장치 및 방법
US8855138B2 (en) * 2008-08-25 2014-10-07 Qualcomm Incorporated Relay architecture framework
US20100260098A1 (en) * 2009-04-10 2010-10-14 Qualcomm Incorporated Header compression for ip relay nodes
US9674311B2 (en) * 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1377549A (zh) * 1999-09-29 2002-10-30 艾利森电话股份有限公司 一种支持压缩分段头标的分段协议
WO2009099845A2 (en) * 2008-01-30 2009-08-13 Qualcomm Incorporated Relay based header compression
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信系统
CN101369977A (zh) * 2008-09-18 2009-02-18 华为技术有限公司 数据传输的方法、装置和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2464063A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017035752A1 (zh) * 2015-08-31 2017-03-09 华为技术有限公司 一种数据流报头压缩传输方法、系统及控制器、节点

Also Published As

Publication number Publication date
CN101998511B (zh) 2013-04-24
EP2464063A1 (en) 2012-06-13
CN101998511A (zh) 2011-03-30
US20120155375A1 (en) 2012-06-21
ES2489469T3 (es) 2014-09-02
EP2464063B1 (en) 2014-06-04
EP2464063A4 (en) 2012-10-03

Similar Documents

Publication Publication Date Title
WO2011023124A1 (zh) 网络中继场景下的头压缩方法及装置
US11510131B2 (en) Configuration method, data transmission method, and apparatus
EP3117658B1 (en) Bearer mobility and splitting in a radio access network-based, 3rd generation partnership project network having an integrated wireless local area network
US11737128B2 (en) Wireless communications system, base station, mobile station, and processing method
JP5479571B2 (ja) 高度ｌｔｅにおけるセルフバックホール処理及びリレー処理用の無線ベアラ識別
JP5088091B2 (ja) 基地局装置、通信方法及び移動通信システム
TWI420925B (zh) 用於ｉｐ中繼節點的標頭壓縮
JP5680633B2 (ja) バックホールヘッダ圧縮
US20150139184A1 (en) System, User Equipment and Method for Implementing Multi-network Joint Transmission
US9380510B2 (en) Apparatus and method for processing GTP in mobile communication system
US9219537B2 (en) Method and system for transmitting information in relay communication network
WO2016173076A1 (zh) 一种数据中转传输方法、系统和具备中继功能的ue
WO2016173078A1 (zh) 一种数据中转传输方法、系统和具备中继功能的ue
WO2014101062A1 (zh) 用户面数据传输方法、移动管理网元、演进型基站及系统
WO2011018002A1 (zh) 一种传输承载的中继方法、装置和通信系统
CN111988212B (zh) 一种报文传输方法以及相关装置
WO2011079785A1 (zh) 一种传输数据包的方法及装置
WO2021062803A1 (zh) 一种数据包传输方法及装置
WO2020164557A1 (zh) 一种通信方法及相关装置
CN102118791A (zh) 一种传输数据包的方法及装置
WO2017031700A1 (zh) 一种数据包的压缩参数确定方法及相关设备
JP2022549714A (ja) イーサネット・ヘッダ圧縮とロバスト・ヘッダ圧縮の併用
WO2022056708A1 (zh) 通信设备、数据传输的方法和装置
JP6156843B2 (ja) 無線通信方法、そのシステムおよび無線基地局
WO2010088804A1 (zh) 一种中继传输的方法、中继节点和基站

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: 10811284

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010811284

Country of ref document: EP