WO2020199030A1 - 一种压缩处理方法、解压缩处理方法及相关设备 - Google Patents

一种压缩处理方法、解压缩处理方法及相关设备 Download PDF

Info

Publication number
WO2020199030A1
WO2020199030A1 PCT/CN2019/080654 CN2019080654W WO2020199030A1 WO 2020199030 A1 WO2020199030 A1 WO 2020199030A1 CN 2019080654 W CN2019080654 W CN 2019080654W WO 2020199030 A1 WO2020199030 A1 WO 2020199030A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
receiving
context
uncompressed
type
Prior art date
Application number
PCT/CN2019/080654
Other languages
English (en)
French (fr)
Inventor
唐海
Original Assignee
Oppo广东移动通信有限公司
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 Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to CN202110944902.0A priority Critical patent/CN113709812B/zh
Priority to JP2021557688A priority patent/JP2022532020A/ja
Priority to CN201980079482.5A priority patent/CN113228582A/zh
Priority to PCT/CN2019/080654 priority patent/WO2020199030A1/zh
Priority to KR1020217035244A priority patent/KR20210141734A/ko
Priority to EP19922297.7A priority patent/EP3905626B1/en
Publication of WO2020199030A1 publication Critical patent/WO2020199030A1/zh
Priority to US17/411,622 priority patent/US11671870B2/en

Links

Images

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/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling
    • 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
    • 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/28—Timers or timing mechanisms used in protocols
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the present invention relates to the field of information processing technology, in particular to a compression processing method, a decompression processing method, a compression terminal device, a decompression terminal device and a computer storage medium, a chip, a computer readable storage medium, a computer program product, and a computer program.
  • PDU Session can be not only an IP packet type, but also an Ethernet data packet type.
  • PDU Session type is at least one of IPv4, IPv6, and IPv4v6, that is, the data packet corresponding to the PDU session is an IPv4 data packet, an IPv6 data packet, or an IPv4v6 data packet At least one of them.
  • the PDU Session type is Ethernet
  • the PDU session corresponds to an Ethernet data packet.
  • embodiments of the present invention provide a compression processing method, a decompression processing method, a compression terminal device, a decompression terminal device and a computer storage medium, a chip, a computer readable storage medium, a computer program product, and a computer program .
  • a compression processing method including:
  • the state of the Ethernet data packet header includes at least one of the following: uncompressed state and compressed state.
  • a decompression processing method including:
  • Ethernet data is received
  • the decompression state includes at least one of the following: no context state and context state.
  • a compression terminal device including:
  • a first processing unit determining the status of the Ethernet data packet header to be sent, and processing the data in the Ethernet data packet header to be sent based on the status of the Ethernet data packet header to be sent;
  • the state of the Ethernet data packet header includes at least one of the following: uncompressed state and compressed state.
  • a decompression terminal device including:
  • the second communication unit receives Ethernet data
  • a second processing unit determining a decompression state, and processing the data in the Ethernet data packet header based on the decompression state;
  • the decompression state includes at least one of the following: no context state and context state.
  • a compression terminal device including a processor and a memory.
  • the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the method in the above-mentioned first aspect or various implementation modes thereof.
  • a decompression terminal device including a processor and a memory.
  • the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the method in the above-mentioned second aspect or each of its implementation modes.
  • a chip is provided for implementing any one of the above-mentioned first aspect and second aspect or the method in each implementation manner thereof.
  • the chip includes: a processor, configured to call and run a computer program from the memory, so that the device installed with the chip executes any one of the above-mentioned first aspect and second aspect or any of the implementations thereof method.
  • a computer-readable storage medium for storing a computer program that enables a computer to execute any one of the above-mentioned first aspect and second aspect or the method in each implementation manner thereof.
  • a computer program product which includes computer program instructions that cause a computer to execute any one of the above-mentioned first and second aspects or the methods in each implementation manner thereof.
  • a computer program which when running on a computer, causes the computer to execute any one of the above-mentioned first aspect and second aspect or the method in each implementation manner thereof.
  • the data packet header is compressed, and according to different states, it is determined which method is currently needed for compression or decompression. This solves the problem of how to use Ethernet packet header compression, and reduces the resource overhead of the air interface.
  • Figure 1-1 is a schematic diagram of a system structure
  • Figure 1-2 is a schematic diagram 1 of a communication system architecture provided by an embodiment of the present application.
  • Figure 2-1 is a schematic flowchart of a compression processing method provided by an embodiment of the present application.
  • Figure 3-1 is a schematic diagram 1 of a state transition provided by an embodiment of the present application.
  • Figure 3-2 is a second schematic diagram of a state transition provided by an embodiment of the present application.
  • FIG. 4 is a third schematic diagram of a state transition provided by an embodiment of the present application.
  • FIG. 5 is a fourth schematic diagram of state transition provided by an embodiment of the present application.
  • FIG. 6 is a first schematic diagram of a processing flow provided by an embodiment of the present application.
  • Figure 7 is a schematic diagram of a data packet format in an uncompressed state
  • Figure 8 is a schematic diagram of a data packet format in a compressed state
  • FIG. 9 is a fifth schematic diagram of a state transition provided by an embodiment of the present application.
  • FIG. 10 is a second schematic diagram of a processing flow provided by an embodiment of the present application.
  • Figure 11 is a sixth schematic diagram of state transition
  • Figure 12 is a schematic diagram of state transition seven
  • FIG. 13 is a schematic diagram of the composition structure of a compression end device provided by an embodiment of the present application.
  • FIG. 14 is a schematic diagram of the composition structure of a decompression terminal device provided by an embodiment of the present application.
  • 15 is a schematic diagram of the structure of a communication device provided by an embodiment of the present invention.
  • FIG. 16 is a schematic block diagram of a chip provided by an embodiment of the present application.
  • FIG. 17 is a second schematic diagram of a communication system architecture provided by an embodiment of the present application.
  • GSM Global System of Mobile Communication
  • CDMA Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • GSM Global System of Mobile Communication
  • GPRS General Packet Radio Service
  • LTE Long Term Evolution
  • FDD Frequency Division Duplex
  • TDD Time Division Duplex
  • UMTS Universal Mobile Telecommunication System
  • WiMAX Worldwide Interoperability for Microwave Access
  • the communication system 100 applied by the embodiment of the present application may be as shown in FIG. 1-2.
  • the communication system 100 may include a network device 110, and the network device 110 may be a device that communicates with a terminal device 120 (or called a communication terminal or terminal).
  • the network device 110 may provide communication coverage for a specific geographic area, and may communicate with terminal devices located in the coverage area.
  • the network equipment 110 may be a network equipment (Base Transceiver Station, BTS) in a GSM system or a CDMA system, a network equipment (NodeB, NB) in a WCDMA system, or an evolution in an LTE system Type network equipment (Evolutional Node B, eNB or eNodeB), or a wireless controller in the Cloud Radio Access Network (CRAN), or the network equipment may be a mobile switching center, a relay station, an access point, In-vehicle devices, wearable devices, hubs, switches, bridges, routers, network side devices in 5G networks, or network devices in the future evolution of the Public Land Mobile Network (PLMN), etc.
  • BTS Base Transceiver Station
  • NodeB, NB network equipment
  • LTE system Type network equipment Evolutional Node B, eNB or eNodeB
  • CRAN Cloud Radio Access Network
  • the network equipment may be a mobile switching center, a relay station, an access point, In-vehicle devices, wearable
  • the communication system 100 also includes at least one terminal device 120 located within the coverage area of the network device 110.
  • the "terminal equipment” used here includes but is not limited to connection via wired lines, such as via public switched telephone networks (PSTN), digital subscriber lines (Digital Subscriber Line, DSL), digital cables, and direct cable connections ; And/or another data connection/network; and/or via a wireless interface, such as for cellular networks, wireless local area networks (WLAN), digital TV networks such as DVB-H networks, satellite networks, AM- FM broadcast transmitter; and/or another terminal device that is set to receive/send communication signals; and/or Internet of Things (IoT) equipment.
  • a terminal device set to communicate through a wireless interface may be referred to as a "wireless communication terminal", a "wireless terminal” or a "mobile terminal”.
  • direct terminal connection (Device to Device, D2D) communication may be performed between the terminal devices 120.
  • the number corresponding to any one of the English letters representing the number mentioned in this application may be the same or different. If the values of N and M are the same, they can also be different. In addition, the number may be an integer greater than or equal to 1.
  • the embodiment of the application provides a compression processing method, as shown in Figure 2-1, including:
  • Step 21 Determine the status of the Ethernet packet header to be sent
  • Step 22 Based on the state of the Ethernet data packet header to be sent, process the data in the Ethernet data packet header to be sent;
  • the state of the Ethernet data packet header includes at least one of the following: uncompressed state and compressed state.
  • This embodiment can be applied to a sending device.
  • a sending device can be a terminal device or a network device. Any device that needs to send data can be the sending device described in this embodiment.
  • the compressed state may include compressed and uncompressed situations; or, the compressed state may also be understood as including the initialization state and the update state IR (initialization and refresh), that is, the uncompressed state.
  • the compression state includes at least one of the following: a partial data compression state and a full data compression state.
  • initialization and update state IR initialization and Refresh
  • intermediate state FO First order
  • highest state SO Second order
  • the highest state SO (Second order) may be a full data compression state
  • the intermediate state may be a partial data compression state.
  • step 22 it may also include sending the Ethernet data packet including the processed Ethernet data packet header.
  • determining the status of the Ethernet data packet header to be sent includes: determining whether the status is changed, and determining the status of the Ethernet data packet header to be sent.
  • the first preset rule includes at least one of the following:
  • N is an integer
  • the compression state of the Ethernet data packet header to be sent currently can be determined based on the first preset rule.
  • header compression state is named from front to back according to the different efficiency of header compression (from low to high), which represents the initial state, the intermediate state and/or the complete state.
  • determining the state transition between different states based on the period can be that during the processing, the switch between multiple states can be determined based on the preset period, and then the Ethernet data packet header to be used currently can be determined status.
  • the switch between multiple states can be determined based on the preset period, and then the Ethernet data packet header to be used currently can be determined status.
  • the two states refer to Figure 3-1.
  • the current cycle can be Determine the status of the current data packet to be sent.
  • the three states it is also possible to determine the state of the data packet to be sent according to the current cycle.
  • determining the state transition between different compression states is similar to the above. You can set the same or different timers for different states. When the timer's duration reaches the corresponding duration, switch from one state to another. A state, for example, after the timer duration for the compressed state is reached, it switches to the uncompressed state, and vice versa. Then the current state is determined according to the timer to control the state of the Ethernet data packet header to be sent.
  • the sending N data packets in the same compression state to switch to another compression state includes one of the following:
  • the partial data compression state is converted to the full data compression state
  • the partial data compression state is converted to the uncompressed state.
  • N data packets in a certain state can be understood as sending N data packets in a certain state continuously, or discontinuously sending N data packets in a certain state. Usually, it is possible to continuously send N data packets in a certain state.
  • the next state when multiple data packets in one of the states are sent, switch to the next state.
  • the next state when there are two states, the next state can be the compressed state.
  • the next state can be a partial data compression state or a full data compression state.
  • the next state may be an uncompressed state.
  • the original state is the full data compression state
  • the next state is the partial data compression state or the uncompressed state.
  • the next state can be all data compressed or uncompressed. Specifically, the next state can be determined according to the preset protocol.
  • the method for determining the state of the Ethernet data packet header currently to be sent in this embodiment can be based on the state of the data packet header in at least one Ethernet data packet that has been sent currently. If the number of data packets is less than N, the current Ethernet data packet to be sent is still sent in this state. If it is equal to N, then the Ethernet data packet header is processed in another state and the Ethernet data packet is sent.
  • the transition from one state to another state includes one of the following:
  • Both M and C are integers greater than or equal to 1.
  • the M Cs can be the same or different.
  • M can be less than C. That is to say, when the continuous reception is judged, a smaller number can be used to determine whether to perform a state transition; when the confirmation message is not continuously received At this time, that is, there may be non-confirmation information in the middle, then at this time, you can receive a few more non-continuous confirmation messages to determine the state transition.
  • M is greater than C, and the specifics can be determined according to the agreement between the two parties.
  • the original uncompressed state is used to process the Ethernet data packet header. If M consecutive confirmation messages or C non-consecutive confirmation messages for the data packet are received, it will be switched to the compressed state.
  • the Ethernet data packet header is processed, and when there are three states, it can be converted to a partial data compression state or a full data compression state.
  • the original compression state is used to process the Ethernet data packet header. If M consecutive confirmation messages or C non-consecutive confirmation messages for the data packet are received, it will be switched to the uncompressed state for Ethernet The network data packet header is processed.
  • the original part of the data compression state processes the Ethernet data packet header. If M consecutive confirmation messages or C non-consecutive confirmation messages for the data packet are received, it will switch to the full data compression state. , Or processing the Ethernet packet header in the uncompressed state. Or, the original data compression state is used to process the Ethernet data packet header. If M continuous confirmation messages or C non-continuous confirmation messages for the data packet are received, then partial data compression will be used State or uncompressed state processes the Ethernet packet header.
  • the original state and the received confirmation information can be combined for processing; for example, if the compressed state is currently used, the continuous confirmation information received is less than M, or , When the received discontinuous confirmation information is less than C, the current state is kept unchanged and the data packet header is processed; otherwise, the uncompressed state is used for processing. Other scenarios are similar, so I won't be exhaustive here.
  • ACK confirmation information
  • three types of ACK feedback can also be used.
  • the processing methods of the two types and three types of confirmation information are respectively explained below:
  • the first number of ACKs of the first type it can transition from the uncompressed state or the partially compressed state to the fully compressed state; receiving the second number of ACKs of the second type, it can transition from the uncompressed state to the partially compressed state . That is to say, the first type of confirmation information (ACK) is used to trigger the state transition to the most efficient state; the second type of confirmation information is used to trigger the state transition to a higher efficiency state.
  • the first number and the second number may be the same or different, and both are integers greater than or equal to 1.
  • the third number of first-type confirmation messages are received, which can be from the uncompressed state to the fully compressed state;
  • the fourth quantity of the second type of confirmation message is received, which can be from the partial data compression state to the full data compression state;
  • the fifth number of the third type of confirmation information is received, which can be from the uncompressed state to the partially compressed state.
  • the first type of confirmation information is used to trigger the migration to the full data compression state;
  • the second type of confirmation information is used to trigger the migration of part of the data compression state to the full data compression state;
  • the third type of confirmation information is used This causes the uncompressed state to migrate to a more efficient partial data compression state.
  • the third, fourth, and fifth numbers are all integers greater than or equal to 1, and are not necessarily the same.
  • the number of received confirmation messages can be different from the number of sent Ethernet data headers.
  • the received confirmation message The number can be less than or equal to N.
  • the transition from one state to another state includes one of the following:
  • K and L are integers greater than or equal to 1.
  • K and L may be the same or different.
  • the original uncompressed state is used to process the Ethernet data packet header. If K continuous non-confirmation messages or L non-contiguous non-confirmation messages for the data packet are received, then the compression is switched to The state processes the Ethernet data packet header. When there are three states, it can be converted to a partial data compression state or a full data compression state.
  • the original compression state is used to process the Ethernet data packet header. If K continuous non-confirmation messages or L non-contiguous non-confirmation messages for the data packet are received, the non-compression state is switched to Process the Ethernet packet header.
  • the original part of the data compression state processes the Ethernet data packet header. If K continuous non-confirmation messages or L non-contiguous non-confirmation messages for the data packet are received, it will switch to using all data The Ethernet data packet header is processed in the compressed or uncompressed state. Or, the original data compression state is used to process the Ethernet data packet header, and if K continuous non-confirmation messages or L non-contiguous non-confirmation messages for the data packet are received, it will be converted to partial The data compression state or the uncompressed state processes the Ethernet data packet header.
  • the original state and the received confirmation information can be combined for processing; for example, if the compressed state is currently used, the continuous non-confirmation information received is less than K, Or, when the received non-continuous non-acknowledgement information is less than L, the data packet header is processed with the current state unchanged; otherwise, the uncompressed state is used for processing. Other scenarios are similar, so I won't be exhaustive here.
  • the transition from one state to another state when receiving non-confirmation information includes at least one of the following:
  • a first-type non-confirmed messages When receiving A first-type non-confirmed messages, or receiving consecutive F first-type non-confirmed messages, switch from the full data compression state to the partial data compression state;
  • a and F are integers greater than or equal to 1;
  • the partial data compression state is converted to the uncompressed state
  • the partial data compression state is converted to the uncompressed state
  • the partial data compression state is converted to the uncompressed state
  • the first type of non-confirmed information, the second type of non-confirmed information, and the third type of non-confirmed information are all different.
  • the first type of non-confirmation information is used for feedback corresponding to the compression state of all data, and correspondingly, it can be used to control the conversion of all the data compression state to the uncompressed state, or control the conversion of the compression state to the uncompressed state.
  • the second type of non-acknowledgment information is used for the feedback of the corresponding partial data compression state, and accordingly, it can make the sending end convert the partial data compression state to the uncompressed state.
  • the third type of non-acknowledgement information is used for feedback corresponding to all data compression states, and accordingly enables the sender to convert all data compression states into partial data compression states.
  • the first type of non-confirmed information is used for feedback on the compression state of all data, and accordingly, the sender can convert all data compression states to uncompressed states; or, first The non-acknowledgement information is used for feedback of all data compression states, and the corresponding sending end converts all data compression states into partial data compression states.
  • the second type of non-acknowledgement information is for the feedback of the partial data compression state, and correspondingly, the sender switches from the partial data compression state to the uncompressed state.
  • the first type of non-confirmed information is used for feedback to the uncompressed state.
  • the sender can convert all or part of the data compression state to the uncompressed state ;
  • the second type of non-confirmation information is for the feedback to the partial data compression state, and accordingly, the sender switches from the full data compression state to the partial compression state.
  • the first type of non-confirmed information is used for feedback of all data compression states. Accordingly, the sender can convert part of the data compression state to uncompressed state, or to all Data compression status.
  • the second type of non-confirmed information can be used for feedback on the uncompressed state. Accordingly, the sender can convert the non-compressed state to the full data compressed state or part of the data compressed state; the third type of non-confirmed information is used for partial data compression State feedback, correspondingly, the sender can convert part of the data compression state to the uncompressed state or the entire data compression state.
  • non-confirmed information can correspond to different states or correspond to different state transitions. It should be understood that the state of non-confirmed information is converted to lower efficiency or The least efficient state transition.
  • the sender when determining its own state, can determine the current state to be adopted according to the original state and the situation of receiving the first, second or third type of non-confirmation information.
  • the initial state is a partial data compression state
  • the partial data compression state is converted to the uncompressed state
  • this scenario can also be combined with cycles or timers for further processing.
  • switch to another state such as switch to the compressed state or All data compression status, or partial data compression status.
  • the duration of the timer when the initial state is the uncompressed state, when the duration of the timer is met, it can be switched to another state, such as switching to the compressed state or all data compression state, or partial data compression state.
  • the receiving end may send a corresponding instruction, and determine which state to transition to based on the content of the instruction. For example, the initially sent data packet is in a compressed state, and when a specific instruction fed back by the receiving end is received, the instruction content is converted to an uncompressed state, and the conversion is performed based on the instruction. That is, when determining the compression of the data packet header currently to be sent, it is determined to send based on the state after the conversion of the specific instruction. Or when it is currently in the partial data compression state, it is determined to switch to the full data compression state according to a specific instruction, or it can also be switched to the uncompressed state according to a specific instruction.
  • the specific instructions can also be integrated with the aforementioned confirmation information or non-confirmation information, timers and other rules. For example, if the third type of non-acknowledgement information is currently received, it needs to be converted from the initial state of all data compression states to the uncompressed state, and at the same time a specific instruction is received, and its content is to switch from the initial state of all data compression states to partial data compression states. . At this time, how to deal with can be determined according to the priority of various preset rules. For example, the priority of a specific instruction is higher, and the state can be converted to a partial data compression state based on the content of the specific instruction.
  • the conversion of the state of the Ethernet data packet header is described with reference to Figure 3-2 to illustrate the transition between the two states, that is, the uncompressed state and the compressed state: the transition from the uncompressed state to the compressed state can be The state transition caused by the rule of timer timeout, it should be understood that although it is not shown in the figure, in fact, the above-mentioned various rules can cause state transition, but the description will not be repeated here; transition from compressed state to uncompressed state , May be due to the timer timeout, the figure also indicates that it may be due to the receipt of non-acknowledgment information (NACK), where the received NACK can be multiple received, or multiple NACK received continuously; the same, although the figure shows State transitions triggered by other rules can actually be triggered by other rules, such as periodic, or receiving instructions, etc., which are the same as those described in the foregoing embodiment, and will not be repeated here.
  • NACK non-acknowledgment information
  • Step 31 Receive Ethernet data
  • Step 32 Determine the decompression state, and process the data in the Ethernet data packet header based on the decompression state;
  • the decompression state includes at least one of the following: no context state and context state.
  • the context state includes at least one of the following: static context state and all context state.
  • the decompression state can correspond to the aforementioned state, or there can be two or three.
  • there are two decompression states there is no context state, and it can also be a state without decompression and there is a context state. Can be decompressed state.
  • the non-context state can also be a state that does not need to be decompressed
  • the static context state can be a partially decompressed state
  • the entire context state can be a fully decompressed state.
  • the process of determining the decompression state may include determining whether the state has changed.
  • the process of determining the decompression state may be performed according to a preset rule, that is, corresponding to the sending end, there is a second preset rule for decompression corresponding to compression, which may specifically include:
  • the second preset rule includes at least one of the following:
  • H is an integer
  • W is an integer
  • R is an integer; where the first type and the second type are different;
  • determining the state transition between different decompression states based on the period can be that during the processing, the switch between multiple decompression states can be determined based on the preset period, and then the current one to be used can be determined The status of the Ethernet packet header.
  • the switch between multiple decompression states can be determined based on the preset period, and then the current one to be used can be determined The status of the Ethernet packet header.
  • the two states refer to Figure 4.
  • the current cycle can be Determine the decompression status of the current packet.
  • determining the state transition between different decompression states is similar to the above. You can set the same or different timers for different states. When the timer's duration reaches the corresponding duration, from a decompression state Switch to another decompression state, for example, after the timer duration for the context state is reached, switch to the contextless state, and vice versa. Then the current state is determined according to the timer to control the state of the Ethernet data packet header to be sent.
  • H is an integer, including one of the following:
  • the state changes from the no context state to the context state
  • the context state is changed to the no context state
  • the static context state is converted to all context states
  • the all context states are converted to static context states
  • the static context state is converted to the non-context state.
  • H data packets in any state can be understood as receiving H data packets in one of the decompressed states continuously, or discontinuously receiving H data packets in a certain state in the decompressed state package. It is usually possible to continuously receive H data packets in a certain state.
  • the next state when receiving multiple data packets in one of the decompression states, switch to the next decompression state.
  • the next state when there are two states, the next state can be There is a context state; when there are three states, the next state can be a static context state, or all context states. Further, when the original state is all context states, the next state can be a static context state. Or, when there are three states, the original state is all context state, then the next state is static context state or no context state. In the three states, there is another situation.
  • the next state When it was originally a static context state, the next state can be a no-context state or a full-context state. Specifically, the next state can be determined according to the preset protocol.
  • the method for determining the current decompression status in this embodiment can be based on the decompression status of at least one currently received data packet. For example, if the number of data packets currently processed in a decompression state is less than H, then still Use this decompression state for processing, if it is equal to or greater than H, then switch to using another decompression state to process the Ethernet data packet header.
  • the receiving or continuously receiving W data packets of the first type, and converting from one decompression state to another decompression state includes:
  • the static context state is converted to all context states.
  • the transition from one decompression state to another decompression state includes:
  • the context state is changed to the non-context state
  • it may also include the transition from one decompression state to another decompression state when Q data packets of the third type are received or continuously received, including:
  • the static context state is converted to all context states.
  • a data packet of the first type can be a data packet in an uncompressed state.
  • the state can be converted from the non-contextual state to the contextual state; or, when there are three states, it can be converted from the non-contextual state to the static context state, or from the non-contextual state to the full-context state.
  • the data packet of the first type may be a data packet in an uncompressed state.
  • the compression end will switch to a data packet in an uncompressed state.
  • the corresponding state can be converted from the context state to the non-context state; or, when there are three states, it can be converted from the all context state to the static context state, or from the all context state to the no context state.
  • the second type of data packet can be understood as a compressed data packet.
  • the compression end When multiple data packets of the second type are received or received continuously, it can be considered that the compression end will switch to the uncompressed state, then the corresponding Yes, the decompression side needs to switch the state to a contextless state.
  • the compression end When there are three decompression states, it can be considered that the compression end may transition from the compression state to the partial data compression state, and the corresponding decompression end can change the state to a static context state; or, it can be considered that the compression end will transition to a non-compression state.
  • the compressed state correspondingly, the decompressing end converts the decompressed state to a no context state.
  • the third type of data packet can be understood as part of the data compression state of the compression end.
  • the compression end will switch to the full data compression state, then the corresponding Yes, the decompression side needs to switch the state to all context states.
  • the compression end may transition to an uncompressed state, and the corresponding decompression end may transition the state to a contextless state.
  • the sending end may indicate the decompression state to be adopted by the receiving end. This situation may follow the sending end, that is, the sending end may follow The state of itself indicates which decompression state is used for processing.
  • the sending time of this indication can be sent when the sending end has a state transition, or it can also be sent from the feedback information when the request information sent is received. Or, every time data is sent, a corresponding decompression state indication is sent along with the data.
  • the transition to another decompression state can be understood as a transition to a lower state.
  • the transition to a lower state For example, when all context decompression fails, it can be transitioned to a static context state. Add compression, if it fails again, you can switch to a contextless state. Of course, it can also be like a high state transition, for example, when the contextless state fails, it can be converted to a static context, or it can also be a full context state.
  • the receiving end will determine the migration and decompression state when sending or continuously sending multiple confirmation messages, that is, when continuously successfully processing a data packet in a decompression state. For example, it can be transferred to a higher state, for example, from a no-context state to a full context state, or it can be converted to a static context state; or, from a static context state to a full context state.
  • the decompression state can be determined to migrate, for example, it can be migrated to a lower state , Which can be a transition from a context state to a non-context state; or, a transition from a full context state to a static context state, or a transition from a full context state to a non-context state. It can also transition from a static context state to a contextless state.
  • Figure 5 shows that in the two decompression states, the two decompression states can be converted to each other.
  • the timer of the non-context state expires, it can be converted to the context state, or it can be received or succeeded in the contextless state.
  • the state transition can also be controlled according to a combination of one or more of the aforementioned second preset rules.
  • the timer can expire, or the data packet cannot be successfully received, or the data packet cannot be decompressed, it will switch to the non-context state.
  • it can also be based on the aforementioned second preset rule.
  • the combination of one or more rules controls the state transition, which will not be repeated here.
  • FIG. 5 only illustrates the transition between the two states, in fact the transition between the three states is similar, but it is not shown in the figure.
  • the terminal device can be a user equipment (UE ), the network device may be a base station on the network side.
  • UE user equipment
  • the sending end is a network device and the receiving end is a terminal device.
  • it may be a processing situation for sending and receiving downlink data. No matter which device is used as the sending end or the decompressing end device, the processing method is the same, but it is not exhaustively listed in this embodiment.
  • Step 41 The base station configures the header compression parameters for the Ethernet data packet; transmits the configuration data through the RRC message, and configures the Ethernet data packet header compression configuration for the UE.
  • the indication can include an indication of whether or not the header is compressed, and the method of header compression;
  • Step 42 The UE confirms whether to perform header compression and how to perform header compression according to the instructions of the base station.
  • the UE determines whether to perform Ethernet header compression according to the Ethernet data packet header compression configuration information sent by the base station, and which sub-header/sub-header type to perform header compression and so on.
  • header compression can only be performed on certain fields: destination address DESTINATION ADDRESS, source address SOURCE ADDRESS, type or length TYPE/LENGTH, virtual domain Q-TAGs (including all sub-fields);
  • header compression processing is performed on the static or unchanged part of the Ethernet data packet header.
  • the specific object or field or field type for header compression may be pre-written in the protocol, or may be indicated in the RRC configuration.
  • Static field types including but not limited to at least one of the following: DESTINATION ADDRESS, SOURCE ADDRESS, TYPE/LENGTH, Q-TAGs (including all sub-fields);
  • Variable field type including but not limited to at least one of the following: TYPE, PRI/PCP, CFI/DEI.
  • Step 43 The UE performs header compression based on the above steps, which also includes state transition.
  • the initial header compression state is the uncompressed state or the IR state.
  • the UE When the header compression function is started, or at the first moment, the UE (compression end) is in the uncompressed state or IR state, and the UE sends uncompressed Ethernet data packets.
  • Ethernet data packet header compression identification includes at least one of the following: Ethernet data packet header compression identification, context identification, check sequence/identification FCS, indication of header compression, serial number SN, Cyclic redundancy check CRC, uncompressed domain/subheader identification, uncompressed domain/subheader indication.
  • the format of the Ethernet data packet header is: data packets in a compressed state and data packets in an uncompressed state adopt different formats; that is, independent packet formats, that is, different types of packets use different packet formats. For example, define at least one packet format that performs compression of the Ethernet data packet header, and a packet format of an uncompressed (contains complete packet information) Ethernet frame. And/or, the compressed data packet and the uncompressed data packet adopt the same format, and the compressed data packet and the uncompressed data packet have different values in at least one identification bit. That is, a unified package format, that is, compressed packages and non-compressed packages (containing complete package information) use the same package format.
  • the data packet formats of different states are shown in Figures 7 and 8. It can be seen that the values of the identification bits of the compressed packet types in Figures 7 and 8 are different, so as to distinguish the two types. Among them, for the format of the uncompressed state, see Figure 7, which can be "1111110D” or "11111110"; in the data packet format of the compressed state in Figure 8, the value of the flag bit is "11111000", you can see The data packets of different states can be distinguished by the value of the flag.
  • Figure 7 shows the format of two data packets, both of which represent data packets in an uncompressed state. It can be seen that they can include dynamic links and static links, or only dynamic links; in Figure 8, it can be seen that compressed
  • the data packet format of the state may not include the static connection and the dynamic link, or it may include one of the static connection and the dynamic link.
  • the data packet format for the partial data compression state and the entire data compression state can also be different. See also Figure 8.
  • the format of the data packet in the partial data compression state can be 1 on the left in the figure, that is, it contains a static link and the format
  • the identification bit of is "11111000", or an intermediate format that only contains dynamic links, and the identification bit is "11111000”; and the format of all data compression states can be excluding static links and dynamic links, and the format is " 11111000".
  • the different states of the data packets are distinguished by different identifiers (that is, the different values of the identification bits). For example, the identifier of some data packets in the compressed state is "11111000”, and the identifier of all data packets in the compressed state is " 11111100", the identifier of the uncompressed data packet is "11111110".
  • Step 44 Send the compressed package to the base station.
  • the UE After sending N uncompressed Ethernet data packets, the UE performs a state transition, and the state transitions to the compressed state or the CO state.
  • the UE state transitions to the low compression state, that is, the uncompressed state after the timer expires.
  • the initial uncompressed state after sending N uncompressed data packets, can be converted to compressed state; and then can be combined with the timer, when the timer reaches the timeout period , Switch to uncompressed state.
  • the compression end and the decompression end migrate between these states according to certain rules to complete the header compression and decompression operations.
  • the base station acts as the decompression terminal, decompresses the compressed package, and then submits the decompressed package upwards, which can specifically include:
  • Step 45 The base station performs decompression processing, which includes state transition.
  • the base station determines the type of the received packet (whether compressed or not) according to the corresponding rules and the mapping relationship, updates/stores the context of the uncompressed packet, and checks the received packet.
  • the compressed package is decompressed, and the corresponding state migration is performed.
  • the initial decompression state is the No context state.
  • the base station (decompression end) is in a contextless state. After the base station receives the uncompressed Ethernet data packet sent by the compression end, it will follow a different path (context ID) to the data packet. Etc.) to update or store the context.
  • the decompression end After receiving N uncompressed Ethernet data packets or successfully receiving/decompressing N uncompressed Ethernet data packets, the decompression end performs state migration and migrates to the high compression state, that is, the state with context, which can be called Full context state, or static context state.
  • the base station When the decompression end, that is, the base station, is in the state where the context is stored, it can be called the full context state or the static context state. After timeout, the base station state transitions to the low compression state, that is, the No context state.
  • the compression side After the compression side sends multiple packets in the uncompressed state (IR state), it transitions to the partial data compression state (FO state), and after sending multiple packets in the partial data compression state (FO state), it transitions to the full data compression state (SO state) ).
  • the full data compression state SO state
  • the timer expires and returns to the partial data compression state (FO state)
  • the partial data compression state (FO state) timer expires, it returns to the uncompressed state (IR state).
  • the decompression end can also handle three states, such as:
  • a similar mechanism can be used, or a different mechanism can be used, for example, a timer method can be used for both.
  • a timer method can be used for both.
  • some use a timer mechanism and some use a method of sending multiple packets. There is no restriction here.
  • Ethernet data packet header compression compression end and/or decompression end state transition feedback-based state transition method
  • Step 51 The base station configures the Ethernet data packet header compression parameters, performs configuration data transmission for the UE and transmits the Ethernet data packet header compression configuration. For example, the base station configures the parameters of the Ethernet frame header compression through the RRC message.
  • Step 52 The UE confirms whether to perform header compression and how to perform header compression according to the instructions of the base station.
  • the UE determines whether to perform Ethernet header compression, which sub-header/sub-header type to perform header compression, and so on. For example, perform header compression processing on the source address, target base station, Ethernet type, and T-tags in the Ethernet header. For example, the header compression process is performed on the static or unchanged part of the Ethernet header.
  • the specific object or field or field type for header compression may be pre-written in the protocol, or may be indicated in the RRC configuration.
  • Step 53 Based on the above steps, the UE performs a header compression operation, which includes state transition.
  • the initial header compression state is the uncompressed state or the IR state.
  • FIG. 11 A possible state transition diagram is shown in Figure 11.
  • the UE compression end
  • the UE sends uncompressed Ethernet data packets.
  • the UE After sending N uncompressed Ethernet data packets, the UE performs a state transition, and the state transitions to the compressed state or the CO state.
  • the UE when the UE is in the uncompressed state or the IR state, the UE sends out N data packets in the uncompressed state and receives N acknowledgement messages (ACK) fed back by the decompression end device, and then performs a state transition, such as migration To the compressed state or the CO state; correspondingly, the decompression end, after receiving, or successfully receiving, or successfully decompressing M uncompressed data packets, will it feedback M confirmation messages to the UE, and at the same time, the decompression end Will move to a high state.
  • ACK acknowledgement messages
  • M and N are different, and M can be smaller than N.
  • the UE state transitions to the low compression state , That is, the uncompressed state.
  • the UE when the UE is in the compressed state or the CO state, the UE sends out Y data packets in the compressed state and receives L non-acknowledgement messages (NACK) fed back by the decompression end device, the state transition is performed to transition to low compression Status, such as uncompressed state; correspondingly, the decompression end cannot receive or successfully decompress L compressed data packets, it will feedback L non-acknowledgement information (NACK) to the UE, and at the same time, the decompression end will Migrate to a low state.
  • L and Y can be different, for example, L can be smaller than Y.
  • the UE submits the compressed package to the PDCP layer and/or RLC layer processing.
  • Step 54 Send the compressed data packet to the base station.
  • the base station serves as the decompression terminal, decompresses the compressed package, and then submits the decompressed package upwards
  • Step 55 The base station performs decompression processing, which also includes state transition processing.
  • Step 56 The base station sends a feedback packet to the UE.
  • the base station determines the type of the received packet (whether compressed or not) according to the corresponding rules and mapping relationship, updates/stores the context of the uncompressed packet, and compares the received packet The compressed package is decompressed, and the corresponding state migration is performed.
  • the initial decompression state is the No context state.
  • the base station (decompression end) is in the no-context state. After the base station receives the uncompressed Ethernet data packet sent by the compression end, it According to different paths (context ID, etc.), context is updated or stored.
  • the decompression end After receiving N uncompressed Ethernet data packets or successfully receiving/decompressing N uncompressed Ethernet data packets, the decompression end performs state migration and migrates to the high compression state, that is, the state with context, which can be called Full context state, or static context state.
  • the decompression end that is, the base station
  • the full context state or the static context state
  • the NACK decompression state of Y compressed packets is decompressed, or, the Ethenet status report is sent
  • the base station state transitions to the low compression state, that is, the No context state.
  • the compression end After the compression end sends N packets in the uncompressed state (IR state), it transitions to the partial data compression state (FO state), and after sending N packets in the partial data compression state (FO state), it transitions to the full data compression state (SO state) ).
  • the decompression end can also handle three states, such as:
  • transition between different states a similar mechanism can be used, or a different mechanism can be used, for example, a timer method can be used for both.
  • some state transitions are performed based on the indication information, and other transitions can be determined based on the received NACK or ACK, which is not exhaustive here.
  • the embodiment of the present application provides a compression terminal device, as shown in FIG. 13, including:
  • the first processing unit 61 determines the state of the Ethernet data packet header to be sent
  • the state of the Ethernet data packet header includes at least one of the following: uncompressed state and compressed state.
  • This embodiment can be applied to a sending device.
  • a sending device can be a terminal device or a network device. Any device that needs to send data can be the sending device described in this embodiment.
  • the compressed state may include compressed and uncompressed situations; or, the compressed state may also be understood as including the initialization state and the update state IR (initialization and refresh), that is, the uncompressed state.
  • the compression state includes at least one of the following: a partial data compression state and a full data compression state.
  • initialization and update state IR initialization and Refresh
  • intermediate state FO First order
  • highest state SO Second order
  • the highest state SO (Second order) may be a full data compression state
  • the intermediate state may be a partial data compression state.
  • a first communication unit which sends the Ethernet data packet including the processed Ethernet data packet header.
  • the first processing unit 61 determines the status of the Ethernet data packet header to be sent, including: determining whether the status is changed, and determining the status of the Ethernet data packet header to be sent.
  • the first preset rule includes at least one of the following:
  • N is an integer
  • the compression state of the Ethernet data packet header to be sent currently can be determined based on the first preset rule.
  • header compression state is named from front to back according to the different efficiency of header compression (from low to high), which represents the initial state, the intermediate state and/or the complete state.
  • the first processing unit 61 includes one of the following:
  • the partial data compression state is converted to the full data compression state
  • the partial data compression state is converted to the uncompressed state.
  • N data packets in a certain state can be understood as sending N data packets in a certain state continuously, or discontinuously sending N data packets in a certain state. Usually, it is possible to continuously send N data packets in a certain state.
  • the next state when multiple data packets in one of the states are sent, switch to the next state.
  • the next state when there are two states, the next state can be the compressed state.
  • the next state can be a partial data compression state or a full data compression state.
  • the next state may be an uncompressed state.
  • the original state is the full data compression state
  • the next state is the partial data compression state or the uncompressed state.
  • the next state can be all data compressed or uncompressed. Specifically, the next state can be determined according to the preset protocol.
  • the method for determining the state of the Ethernet data packet header currently to be sent in this embodiment can be based on the state of the data packet header in at least one Ethernet data packet that has been sent currently. If the number of data packets is less than N, the current Ethernet data packet to be sent is still sent in this state. If it is equal to N, then the Ethernet data packet header is processed in another state and the Ethernet data packet is sent.
  • the first processing unit 61 includes one of the following:
  • Both M and C are integers greater than or equal to 1.
  • the M Cs can be the same or different.
  • M can be less than C. That is to say, when the continuous reception is judged, a smaller number can be used to determine whether to perform a state transition; when the confirmation message is not continuously received At this time, that is, there may be non-confirmation information in the middle, then at this time, you can receive a few more non-continuous confirmation messages to determine the state transition.
  • M is greater than C, and the specifics can be determined according to the agreement between the two parties.
  • the aforementioned first processing unit 61 includes one of the following:
  • K and L are integers greater than or equal to 1.
  • K and L may be the same or different.
  • the first processing unit 61 includes at least one of the following:
  • a first-type non-confirmed messages When receiving A first-type non-confirmed messages, or receiving consecutive F first-type non-confirmed messages, switch from the full data compression state to the partial data compression state;
  • a and F are integers greater than or equal to 1;
  • the partial data compression state is converted to the uncompressed state
  • the partial data compression state is converted to the uncompressed state
  • the partial data compression state is converted to the uncompressed state
  • the first type of non-confirmed information, the second type of non-confirmed information, and the third type of non-confirmed information are all different.
  • a decompression terminal device as shown in FIG. 14, includes:
  • the second communication unit 71 receives Ethernet data
  • the second processing unit 72 determines a decompression state, and processes the data in the Ethernet data packet header based on the decompression state;
  • the decompression state includes at least one of the following: no context state and context state.
  • the context state includes at least one of the following: static context state and all context state.
  • the decompression state can correspond to the aforementioned state, or there can be two or three.
  • there are two decompression states there is no context state, and it can also be a state without decompression and there is a context state. Can be decompressed state.
  • the non-context state can also be a state that does not need to be decompressed
  • the static context state can be a partially decompressed state
  • the entire context state can be a fully decompressed state.
  • the process of determining the decompression state may include determining whether the state has changed.
  • the process of determining the decompression state may be performed according to a preset rule, that is, corresponding to the sending end, there is a second preset rule for decompression corresponding to compression, which may specifically include:
  • the second preset rule includes at least one of the following:
  • H is an integer
  • W is an integer
  • R is an integer; where the first type and the second type are different;
  • determining the state transition between different decompression states based on the period can be that during the processing, the switch between multiple decompression states can be determined based on the preset period, and then the current one to be used can be determined The status of the Ethernet packet header.
  • the switch between multiple decompression states can be determined based on the preset period, and then the current one to be used can be determined The status of the Ethernet packet header.
  • the two states refer to Figure 4.
  • the current cycle can be Determine the decompression status of the current packet.
  • determining the state transition between different decompression states is similar to the above. You can set the same or different timers for different states. When the timer's duration reaches the corresponding duration, from a decompression state Switch to another decompression state, for example, after the timer duration for the context state is reached, switch to the contextless state, and vice versa. Then the current state is determined according to the timer to control the state of the Ethernet data packet header to be sent.
  • the second processing unit 72 includes one of the following:
  • the state changes from the no context state to the context state
  • the context state is changed to the no context state
  • the static context state is converted to all context states
  • the all context states are converted to static context states
  • the static context state is converted to the non-context state.
  • H data packets in any state can be understood as receiving H data packets in one of the decompressed states continuously, or discontinuously receiving H data packets in a certain state in the decompressed state package. It is usually possible to continuously receive H data packets in a certain state.
  • the second processing unit 72 includes:
  • the static context state is converted to all context states.
  • the second processing unit 72 includes:
  • the context state is changed to the non-context state
  • the second processing unit 72 includes:
  • the static context state is converted to all context states.
  • Ethernet data packet header compression identification includes at least one of the following: Ethernet data packet header compression identification, context identification, check sequence/identification FCS, indication of header compression, serial number SN, Cyclic redundancy check CRC, uncompressed domain/subheader identification, uncompressed domain/subheader indication.
  • the format of the Ethernet data packet header is: data packets in a compressed state and data packets in an uncompressed state adopt different formats; that is, independent packet formats, that is, different types of packets use different packet formats. For example, define at least one packet format that performs compression of the Ethernet data packet header, and a packet format of an uncompressed (contains complete packet information) Ethernet frame. And/or, the compressed data packet and the uncompressed data packet adopt the same format, and the compressed data packet and the uncompressed data packet have different values in at least one identification bit. That is, a unified package format, that is, compressed packages and non-compressed packages (containing complete package information) use the same package format.
  • the data packet formats of different states are shown in Figures 7 and 8. It can be seen that the values of the identification bits of the compressed packet types in Figures 7 and 8 are different, so as to distinguish the two types. Among them, for the format of the uncompressed state, see Figure 7, which can be "1111110D” or "11111110"; in the data packet format of the compressed state in Figure 8, the value of the flag bit is "11111000", you can see The data packets of different states can be distinguished by the value of the flag.
  • Figure 7 shows the formats of two data packets, both of which represent data packets in an uncompressed state. It can be seen that they can include dynamic links and static links, or only dynamic links; in Figure 8, it can be seen that compressed
  • the data packet format of the state may not include the static connection and the dynamic link, or it may include one of the static connection and the dynamic link.
  • the data packet format for the partial data compression state and the entire data compression state can also be different. See also Figure 8.
  • the format of the data packet in the partial data compression state can be 1 on the left in the figure, that is, it contains a static link and the format
  • the identification bit of is "11111000", or an intermediate format that only contains dynamic links, and the identification bit is "11111000”; and the format of all data compression states can be excluding static links and dynamic links, and the format is " 11111000”.
  • the different states of the data packets are distinguished by different identifiers (that is, the different values of the identification bits). For example, the identifier of some data packets in the compressed state is "11111000”, and the identifier of all data packets in the compressed state is " 11111100", the identifier of the uncompressed data packet is "11111110".
  • FIG. 15 is a schematic structural diagram of a communication device 800 provided by an embodiment of the present application.
  • the communication device may be the aforementioned terminal device or network device in this embodiment.
  • the communication device 800 shown in FIG. 16 includes a processor 810, and the processor 810 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the communication device 800 may further include a memory 820.
  • the processor 810 can call and run a computer program from the memory 820 to implement the method in the embodiment of the present application.
  • the memory 820 may be a separate device independent of the processor 810, or may be integrated in the processor 810.
  • the communication device 800 may further include a transceiver 830, and the processor 810 may control the transceiver 830 to communicate with other devices. Specifically, it may send information or data to other devices, or receive other devices. Information or data sent by the device.
  • the transceiver 830 may include a transmitter and a receiver.
  • the transceiver 830 may further include an antenna, and the number of antennas may be one or more.
  • the communication device 800 may specifically be the compression terminal device or the decompression terminal device of the embodiment of the application, and the communication device 800 may implement the corresponding processes implemented by the mobile terminal/terminal device in the various methods of the embodiments of the application. , For the sake of brevity, I will not repeat it here.
  • FIG. 16 is a schematic structural diagram of a chip of an embodiment of the present application.
  • the chip 900 shown in FIG. 16 includes a processor 910, and the processor 910 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the chip 900 may further include a memory 920.
  • the processor 910 may call and run a computer program from the memory 920 to implement the method in the embodiment of the present application.
  • the memory 920 may be a separate device independent of the processor 910, or may be integrated in the processor 910.
  • the chip 900 may further include an input interface 930.
  • the processor 910 can control the input interface 930 to communicate with other devices or chips, and specifically, can obtain information or data sent by other devices or chips.
  • the chip 900 may further include an output interface 940.
  • the processor 910 can control the output interface 940 to communicate with other devices or chips, and specifically, can output information or data to other devices or chips.
  • the chip can be applied to the compression end device or the decompression end device in the embodiment of the present application, and the chip can implement the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the chip can implement the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the chip mentioned in the embodiment of the present application may also be referred to as a system-level chip, a system-on-chip, a system-on-chip, or a system-on-chip, etc.
  • FIG. 17 is a schematic block diagram of a communication system 1000 according to an embodiment of the present application. As shown in FIG. 17, the communication system 1000 includes a compression terminal device 1010 and a decompression terminal device 1020.
  • the compression end device 1010 can be used to implement the corresponding functions implemented by the terminal device in the above method
  • the decompression end device 1020 can be used to implement the corresponding functions implemented by the network device in the above method.
  • the compression end device 1010 can be used to implement the corresponding functions implemented by the terminal device in the above method
  • the decompression end device 1020 can be used to implement the corresponding functions implemented by the network device in the above method.
  • the processor of the embodiment of the present application may be an integrated circuit chip with signal processing capability.
  • the steps of the foregoing method embodiments can be completed by hardware integrated logic circuits in the processor or instructions in the form of software.
  • the aforementioned processor may be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (ASIC), a ready-made programmable gate array (Field Programmable Gate Array, FPGA) or other Programming logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • DSP Digital Signal Processor
  • ASIC application specific integrated circuit
  • FPGA ready-made programmable gate array
  • the methods, steps, and logical block diagrams disclosed in the embodiments of the present application can be implemented or executed.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • the memory in the embodiment of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), and electrically available Erase programmable read-only memory (Electrically EPROM, EEPROM) or flash memory.
  • the volatile memory may be a random access memory (Random Access Memory, RAM), which is used as an external cache.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • DRAM synchronous dynamic random access memory
  • SDRAM double data rate synchronous dynamic random access memory
  • Double Data Rate SDRAM DDR SDRAM
  • ESDRAM enhanced synchronous dynamic random access memory
  • Synchlink DRAM SLDRAM
  • DR RAM Direct Rambus RAM
  • the memory in the embodiment of the present application may also be static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), Synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection Dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM), etc. That is to say, the memory in the embodiment of the present application is intended to include but not limited to these and any other suitable types of memory.
  • the embodiment of the present application also provides a computer-readable storage medium for storing computer programs.
  • the computer-readable storage medium may be applied to the network device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the computer program causes the computer to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the computer-readable storage medium can be applied to the terminal device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding process implemented by the mobile terminal/terminal device in each method of the embodiment of the present application, for the sake of brevity , I won’t repeat it here.
  • the embodiments of the present application also provide a computer program product, including computer program instructions.
  • the computer program product may be applied to the network device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the computer program instructions cause the computer to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the computer program instructions cause the computer to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • the computer program product can be applied to the mobile terminal/terminal device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding process implemented by the mobile terminal/terminal device in each method of the embodiment of the present application, For brevity, I won't repeat them here.
  • the embodiment of the present application also provides a computer program.
  • the computer program can be applied to the network device in the embodiment of the present application.
  • the computer program runs on the computer, the computer is caused to execute the corresponding process implemented by the network device in each method of the embodiment of the present application.
  • I won’t repeat it here.
  • the computer program can be applied to the mobile terminal/terminal device in the embodiment of the present application.
  • the computer program runs on the computer, the computer executes each method in the embodiment of the present application. For the sake of brevity, the corresponding process will not be repeated here.
  • the disclosed system, device, and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or It can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • each unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of this application essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory,) ROM, random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

Landscapes

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

Abstract

本发明公开了一种压缩处理方法、解压缩处理方法和相关设备，其中方法包括：确定所要发送的以太网数据包头的状态，基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。

Description

一种压缩处理方法、解压缩处理方法及相关设备 技术领域
本发明涉及信息处理技术领域，尤其涉及一种压缩处理方法、解压缩处理方法、压缩端设备、解压缩端设备及计算机存储介质、芯片、计算机可读存储介质、计算机程序产品以及计算机程序。
背景技术
在5G新无线(NR，New Radio)系统中，在PDU会话(session)仅支持互联网协议(IP，Internet Protocl)的基础上，又增加了可以支持以太网。也就是说，PDU Session不仅可以为IP包类型，也可以为以太网数据包的类型类型。如图1-1所述，PDU层PDU layer来说，当PDU Session类型为IPv4、IPv6、IPv4v6中至少之一，即该PDU session对应的数据包为IPv4数据包、IPv6数据包、IPv4v6数据包中至少之一。当PDU Session类型为以太网(Ethernet)时,该PDU会话对应的为以太网数据包。
然而，针对PDU会话中的以太网数据包的压缩处理目前仍未提出相关的处理方式，因此，无法节省以太网数据包的传输资源。
发明内容
为解决上述技术问题，本发明实施例提供了一种压缩处理方法、解压缩处理方法、压缩端设备、解压缩端设备及计算机存储介质、芯片、计算机可读存储介质、计算机程序产品以及计算机程序。
第一方面，提供了一种压缩处理方法，包括：
确定所要发送的以太网数据包头的状态，
基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
第二方面，提供了一种解压缩处理方法，包括：
接收到以太网数据；
确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
第三方面，提供了一种压缩端设备，包括：
第一处理单元，确定所要发送的以太网数据包头的状态，基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
第四方面，提供了一种解压缩端设备，包括：
第二通信单元，接收到以太网数据；
第二处理单元，确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
第五方面，提供了一种压缩端设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第一方面或 其各实现方式中的方法。
第六方面，提供了一种解压缩端设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第二方面或其各实现方式中的方法。
第七方面，提供了一种芯片，用于实现上述第一方面、第二方面中的任一方面或其各实现方式中的方法。
具体地，该芯片包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有该芯片的设备执行如上述第一方面、第二方面中的任一方面或其各实现方式中的方法。
第八方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述第一方面、第二方面中的任一方面或其各实现方式中的方法。
第九方面，提供了一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述第一方面、第二方面中的任一方面或其各实现方式中的方法。
第十方面，提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面、第二方面中的任一方面或其各实现方式中的方法。
通过采用上述方案，在发送以及接受以太网数据包的时候，针对数据包头进行压缩，并根据不同的状态确定当前需要采用哪种方式进行压缩或解压缩。从而解决了如何使用以太网数据包头压缩的问题，同时减少了空口的资源开销。
附图说明
图1-1是一种系统结构示意图；
图1-2是本申请实施例提供的一种通信系统架构的示意性图一；
图2-1是本申请实施例提供的一种压缩处理方法流程示意图；
图2-2是本申请实施例提供的一种解压缩处理方法流程示意图；
图3-1是本申请实施例提供的一种状态转换示意图一；
图3-2是本申请实施例提供的一种状态转换示意图二；
图4是本申请实施例提供的一种状态转换示意图三；
图5是本申请实施例提供的一种状态转换示意图四；
图6是本申请实施例提供的一种处理流程示意图一；
图7是一种非压缩状态的数据包格式示意图；
图8是压缩状态的数据包格式示意图；
图9是本申请实施例提供的一种状态转换示意图五；
图10是本申请实施例提供的一种处理流程示意图二；
图11是一种状态转换示意图六；
图12是一种状态转换示意图七；
图13是本申请实施例提供的一种压缩端设备组成结构示意图；
图14是本申请实施例提供的一种解压缩端设备组成结构示意图；
图15为本发明实施例提供的一种通信设备组成结构示意图；
图16是本申请实施例提供的一种芯片的示意性框图；
图17是本申请实施例提供的一种通信系统架构的示意性图二。
具体实施方式
为了能够更加详尽地了解本发明实施例的特点与技术内容，下面结合附图对本发明实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本发明实施例。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例的技术方案可以应用于各种通信系统，例如：全球移动通讯(Global  System of Mobile communication，GSM)系统、码分多址(Code Division Multiple Access，CDMA)系统、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)系统、通用分组无线业务(General Packet Radio Service，GPRS)、长期演进(Long Term Evolution，LTE)系统、LTE频分双工(Frequency Division Duplex，FDD)系统、LTE时分双工(Time Division Duplex，TDD)、通用移动通信系统(Universal Mobile Telecommunication System，UMTS)、全球互联微波接入(Worldwide Interoperability for Microwave Access，WiMAX)通信系统或5G系统等。
示例性的，本申请实施例应用的通信系统100可以如图1-2所示。该通信系统100可以包括网络设备110，网络设备110可以是与终端设备120(或称为通信终端、终端)通信的设备。网络设备110可以为特定的地理区域提供通信覆盖，并且可以与位于该覆盖区域内的终端设备进行通信。可选地，该网络设备110可以是GSM系统或CDMA系统中的网络设备(Base Transceiver Station，BTS)，也可以是WCDMA系统中的网络设备(NodeB，NB)，还可以是LTE系统中的演进型网络设备(Evolutional Node B，eNB或eNodeB)，或者是云无线接入网络(Cloud Radio Access Network，CRAN)中的无线控制器，或者该网络设备可以为移动交换中心、中继站、接入点、车载设备、可穿戴设备、集线器、交换机、网桥、路由器、5G网络中的网络侧设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)中的网络设备等。
该通信系统100还包括位于网络设备110覆盖范围内的至少一个终端设备120。作为在此使用的“终端设备”包括但不限于经由有线线路连接，如经由公共交换电话网络(Public Switched Telephone Networks，PSTN)、数字用户线路(Digital Subscriber Line，DSL)、数字电缆、直接电缆连接；和/或另一数据连接/网络；和/或经由无线接口，如，针对蜂窝网络、无线局域网(Wireless Local Area Network，WLAN)、诸如DVB-H网络的数字电视网络、卫星网络、AM-FM广播发送器；和/或另一终端设备的被设置成接收/发送通信信号的装置；和/或物联网(Internet of Things，IoT)设备。被设置成通过无线接口通信的终端设备可以被称为“无线通信终端”、“无线终端”或“移动终端”。
可选地，终端设备120之间可以进行终端直连(Device to Device，D2D)通信。
应理解，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
为了能够更加详尽地了解本发明实施例的特点与技术内容，下面结合附图对本发明实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本发明实施例。
需要说明的是，本申请中提到的任意一个代表数目的英文字母对应的数目可以是相同的，也可以是不同。如N和M的取值是相同的，也可以是不同的。另外，所述数目可以为大于等于1的整数。
本申请实施例提供了一种压缩处理方法，如图2-1所示，包括：
步骤21：确定所要发送的以太网数据包头的状态；
步骤22：基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
本实施例可以应用于发送设备，比如可以为终端设备或者可以为网络设备，只要需要进行数据发送的设备均可以为本实施例所述的发送设备。
本实施例中压缩状态可以包括有压缩以及未压缩两种情况；或者，压缩状态还可以理解为：包括初始化状态、和更新状态IR(initialization and Refresh)即非压缩状态。
或者，所述压缩状态包括以下至少之一：部分数据压缩状态、全部数据压缩状态。
也就是说，本实施例中可以存在压缩状态以及非压缩状态这两种情况；也可以存在非压缩状态、部分数据压缩状态以及全部数据压缩状态这三种情况。或者，可以分别称为：初始化、和更新状态IR(initialization and Refresh)，中间状态FO(First order)和最高状态SO(Second order)。其中，最高状态SO(Second order)可以为全部数据压缩状态，中间状态可以为部分数据压缩状态。
需要理解的是，上述步骤22之后，还可以包括发送包含有处理后的以太网数据包头的所述以太网数据包。
步骤21中，确定所要发送的以太网数据包头的状态，包括：确定状态是否变更，确定所要发送的以太网数据包头的状态。
具体的可以包括：
基于第一预设规则，确定所要发送的以太网数据包头的状态；
其中，所述第一预设规则包括以下至少之一：
基于周期，确定在不同状态之间进行状态转换；
基于定时器，确定在不同状态之间进行状态转换；
发送N个在同一个状态的以太网数据包头的数据包，向另一个压缩状态转换；N为整数；
接收到确认信息时，由一个状态转换为另一个状态；
接收到非确认信息时，由一个状态转换为另一个状态；
接收到特定指示时，由一个状态转换为另一个状态。
也就是说，可以基于第一预设规则，来确定当前所要发送的以太网数据包头的压缩状态。
需要说明的是，在下述描述中，是按照头压缩的不同效率(从低到高)来从前到后给出头压缩状态的命名，代表了初始化状态，中间状态和/或完全状态。
具体来说，基于周期确定不同状态之间进行状态转换，可以为在处理过程中，可以基于预设的周期来确定在多个状态之间进行切换，进而可以确定当前所要使用的以太网数据包头的状态。比如，针对两种状态的时候，参见图3-1，针对压缩状态以及非压缩状态，基于在第一个周期中采用压缩状态，在下一个周期采用非压缩状态，那么当前处于哪个周期，就可以确定当前所要发送的数据包的状态为哪种。或者，针对三种状态的时候，也是可以根据当前的周期，确定所要发送的数据包的状态为哪种。
基于定时器，确定在不同压缩状态之间进行状态转换与上述类似，可以为针对不同的状态设置相同或不同的定时器，当定时器的时长达到对应的时长的时候，从一个状态转换至另一个状态，比如，针对压缩状态的定时器时长达到之后，转换至非压缩状态，反之亦然。那么当前根据定时器确定处于哪种状态就控制所要发送的以太网数据包头处于哪种状态。
所述发送N个在同一个压缩状态下数据包，向另一个压缩状态转换，包括以下之一：
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为压缩状态；
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为部分数据压缩状态；
发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为全部数据压缩状态；
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为全部数据压缩状态；
发送N个压缩状态的以太网数据包头的数据包时，由压缩状态转换为非压缩状态；
发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为非压缩状态；
发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为部分数据压缩状态；
发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为非压缩状态。
需要指出的是，上述发送N个某个状态的数据包，可以理解为连续的发送N个其中某一个状态的数据包，或者是，不连续的发送N个某一个状态的数据包。通常可能采用连续发送N个某一个状态的数据包的方式。
也就是说，在发送了多个其中一个状态的数据包的时候，转换至下一个状态，当原来的状态为非压缩状态时，当存在两种状态的时候，下一个状态可以为压缩状态，当存在三种状态的时候，下一个状态可以为部分数据压缩状态，或者全部数据压缩状态。进一步地，当原来的状态为压缩状态的时候，下一个状态可以为非压缩状态。或者，存在三种状态的时候，原来的状态为全部数据压缩状态，那么下一个状态为部分数据压缩状态或非压缩状态。在三种状态的时候下，还存在另一种情况，原来为部分数据压缩状态的时候，下一个状态可以为全部数据压缩状态，还可以为非压缩状态。具体可以根据预设协议来确定下一个状态具体是哪种。
在此基础上，本实施方式确定当前所要发送的以太网数据包头的状态的方式，可以为基于当前已经发送的至少一个以太网数据包中数据包头的状态来判断，比如当前采用一个状态发送的数据包小于N个，那么仍然采用该状态发送当前的所要发送的以太网数据包，如果等于N个，那么转换为采用另一个状态对以太网数据包头进行处理并发送以太网数据包。
所述接收到确认信息时，由一个状态转换为另一个状态，包括以下之一：
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为部分数据压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由部分数据压缩状态转换为全部数据压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为全部数据压缩状态；
M和C均为大于等于1的整数。
其中，M个C可以相同也可以不同，比如，可以为M小于C，也就是说，当判断连续接收的时候，可以较少的数量就能够确定是否进行状态转换；当非连续接收确认信息的时候，也就是中间可能存在非确认信息，那么此时可以多收几个非连续的确认信息再确定状态转换。当然，反之也可以，比如M大于C，具体的可以根据双方协议来确定。
具体来说，原来采用非压缩状态对以太网数据包头进行处理，若接收到针对该数据包的M个连续的确认信息、或者C个非连续的确认信息的时候，就转为采用压缩状态对以太网数据包头进行处理，当存在三种状态的时候，可以转为采用部分数据压缩状态或全部数据压缩状态。
又例如，原来采用压缩状态对以太网数据包头进行处理，若接收到针对该数据包的M个连续的确认信息、或者C个非连续的确认信息的时候，就转为采用非压缩状态对以太网数据包头进行处理。
再例如，原来部分数据压缩状态对以太网数据包头进行处理，若接收到针对该数据包的M个连续的确认信息、或者C个非连续的确认信息的时候，就转为采用全部数据压缩状态、或者非压缩状态对以太网数据包头进行处理。或者是，原来采用全部数据压缩状态对以太网数据包头进行处理，若接收到针对该数据包的M个连续的确认信息、或者C个非连续的确认信息的时候，就转为采用部分数据压缩状态、或者非压缩状态对以太网数据包头进行处理。
在确定当前所要发送的以太网数据包头的状态的时候，可以结合原来的状态、以及接收到的确认信息来进行处理；比如，当前采用压缩状态，那么接收到的连续的确认信息小于M，或者，接收到的非连续的确认信息小于C的时候，保存当前状态不变对数据包头进行处理；否则，就采用非压缩状态进行处理。其他场景类似，这里不再穷举。
又一个情况下，基于确认信息向高压缩状态迁移的时候，还可以采用两类确认信息(ACK)反馈，或三类ACK反馈进行的方式。以下对两类以及三类确认信息的处理方式分别进行说明：
对两类确认信息的处理方式：
收到第一数量个第一类ACK，可以从非压缩状态或部分压缩状态，迁移至全部数据压缩状态；收到第二数量个第二类ACK，可以从非压缩状态迁移到部分数据压缩状态。也就是说，第一类确认信息(ACK)，用于引发状态迁移至最高效率的状态；第二类确认信息用于引发将状态迁移至较高效率的状态。其中，第一数量以及第二数量可以相同可以不同，均为大于等于1的整数。
对三类确认信息的处理方式：
接收到第三数量个第一类确认信息，可以从非压缩状态到全部数据压缩状态；
接收到第四数量个第二类确认信息，可以从部分数据压缩状态到全部数据压缩状态；
接收到第五数量个第三类确认信息，可以从非压缩状态到部分数据压缩状态。
也就是说，本处理方式中，第一类确认信息用于引发迁移至全部数据压缩状态；第二类确认信息用于引发部分数据压缩状态迁移至全部数据压缩状态；第三类确认信息，用于引发非压缩状态迁移至较高效率的部分数据压缩状态。
同样的，本处理方式中，第三、第四、第五数量均为大于等于1的整数，且不一定相同。
还需要指出的是，针对上述两种处理方式中，接收到的确认信息的数量可以与发送以太网数据头的数量不同，比如，发送N个以太网数据包的情况下，接收到的确认信息的数量可以小于或等于N。
前述接收到非确认信息时，由一个状态转换为另一个状态，包括以下之一：
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为非压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由压缩状态转换为非压缩状态；
K和L为大于等于1的整数。
其中，K和L可以相同也可以不同。
具体来说，原来采用非压缩状态对以太网数据包头进行处理，若接收到针对该数据包的K个连续的非确认信息、或者L个非连续的非确认信息的时候，就转为采用压缩 状态对以太网数据包头进行处理，当存在三种状态的时候，可以转为采用部分数据压缩状态或全部数据压缩状态。
又例如，原来采用压缩状态对以太网数据包头进行处理，若接收到针对该数据包的K个连续的非确认信息、或者L个非连续的非确认信息的时候，就转为采用非压缩状态对以太网数据包头进行处理。
再例如，原来部分数据压缩状态对以太网数据包头进行处理，若接收到针对该数据包的K个连续的非确认信息、或者L个非连续的非确认信息的时候，就转为采用全部数据压缩状态、或者非压缩状态对以太网数据包头进行处理。或者是，原来采用全部数据压缩状态对以太网数据包头进行处理，若接收到针对该数据包的K个连续的非确认信息、或者L个非连续的非确认信息的时候，就转为采用部分数据压缩状态、或者非压缩状态对以太网数据包头进行处理。
在确定当前所要发送的以太网数据包头的状态的时候，可以结合原来的状态、以及接收到的确认信息来进行处理；比如，当前采用压缩状态，那么接收到的连续的非确认信息小于K，或者，接收到的非连续的非确认信息小于L的时候，保持当前状态不变对数据包头进行处理；否则，就采用非压缩状态进行处理。其他场景类似，这里不再穷举。
所述接收到非确认信息时，由一个状态转换为另一个状态，包括以下至少之一：
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；A、F为大于等于1的整数；
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由全部数据压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由压缩状态转换为非压缩状态；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由全部数据压缩状态转换为非压缩状态；G和P均为整数；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由压缩状态转换为非压缩状态；
其中，所述第一类非确认信息、第二类非确认信息以及第三类非确认信息均不相同。
这里需要指出的是，上述分支可以在不同情况下进行组合，也就是在不同情况下第一类、第二类以及第三类非确认信息可以不同。
比如，第一类非确认信息用于对应全部数据压缩状态的反馈，相应的，能够用于控制全部数据压缩状态转换为非压缩状态，或者控制压缩状态转换为非压缩状态。第二类非确认信息用于对应部分数据压缩状态的反馈，相应的，能够使得发送端将部分数据压缩状态转换为非压缩状态。第三类非确认信息用于对应全部数据压缩状态的反馈，相应的能够使得发送端将全部数据压缩状态转换为部分数据压缩状态。
又或者，仅采用两类非确认信息，其中，第一类非确认信息用于针对全部数据压缩状态的反馈，相应的，发送端能够将全部数据压缩状态转换为非压缩状态；或者，第一 类非确认信息用于针对全部数据压缩状态的反馈，相应的发送端将全部数据压缩状态转换为部分数据压缩状态。第二类非确认信息针对部分数据压缩状态的反馈，相应的，发送端由部分数据压缩状态转换为非压缩状态。
又或者，仅采用两类非确认信息，其中，第一类非确认信息用于针对到非压缩状态的反馈，相应的，发送端能够将全部数据压缩状态或部分数据压缩状态转换为非压缩状态；第二类非确认信息针对到部分数据压缩状态的反馈，相应的，发送端由全部数据压缩状态转换为部分压缩状态。
再或者，采用三类非确认信息的时候，其中第一类非确认信息用于针对全部数据压缩状态的反馈，相应的，发送端能够将部分数据压缩状态转换为非压缩状态，或者转换为全部数据压缩状态。第二类非确认信息可以用于针对非压缩状态的反馈，相应的，发送端能够将非压缩状态转换为全部数据压缩状态或者部分数据压缩状态；第三类非确认信息用于针对部分数据压缩状态的反馈，相应的，发送端能够将部分数据压缩状态转换为非压缩状态或者全部数据压缩状态。
当然，还可能存在其他的组合情况，总之不同类型的非确认信息能够对应于不同的状态，或者对应与不同的状态转换，需要理解的是，针对非确认信息的状态转换为向较低效率或最低效率的状态的转换。
相应的，发送端在确定自身的状态的时候，可以根据原始的状态以及接收到第一类、第二类或第三类非确认信息的情况来确定当前所要采用的状态。
举例来说，初始状态为部分数据压缩状态，那么在收到第二类非确认信息连续的B个或非连续的E个的时候，由部分数据压缩状态转换为非压缩状态。
需要理解的是，本场景还可以结合周期或定时器来进行进一步处理，比如，当初始状态为非压缩状态的时候，当满足周期时长的时候，切换至另一个状态，比如切换至压缩状态或者全部数据压缩状态、或者部分数据压缩状态。又比如，当初始状态为非压缩状态的时候，满足该定时器的时长的时候，可以切换至另一个状态，比如切换至压缩状态或者全部数据压缩状态、或者部分数据压缩状态。
关于接收到特定指示时，由一个状态转换为另一个状态，可以为由接收端发来相应的指示，基于该指示中的内容确定转换为哪种状态。比如，初始发送的数据包为压缩状态，接收到接收端反馈的特定指示的时候，该指示内容为转换为非压缩状态，则基于该指示进行转换。也就是在确定当前所要发送的数据包头的压缩情况的时候，确定基于特定指示转换后的状态进行发送。或者当前为部分数据压缩状态的时候，根据特定指示来确定转换至全部数据压缩状态，或者还可以为根据特定指示转换为非压缩状态。
还需要指出的是，特定指示还可以与前述确认信息或非确认信息以及定时器等规则综合处理。比如，当前接收到第三类非确认信息，需要由初始状态的全部数据压缩状态转换为非压缩状态，同时接收到特定指示，其内容为由初始状态的全部数据压缩状态转换为部分数据压缩状态。此时可以根据预设的各种规则的优先级来确定如何处理，比如特定指示的优先级较高，那么可以基于特定指示的内容将状态转换为部分数据压缩状态。
上述实施例中，对以太网数据包头的状态的转换，结合图3-2对两种状态之间的转换，也就是非压缩状态以及压缩状态进行说明：由非压缩状态转换至压缩状态可以为定时器超时的规则引发的状态转换，需要理解的是，虽然图中未示意出，但是实际上上述多种规则均可以引发状态转换，只是这里不再重复描述；由压缩状态转换至非压缩状态，可以为由于定时器超时，图中还示意出可以由于接收到非确认信息(NACK)，其中接收到NACK可以为接收到多个，或者连续接收到多个NACK；同样的，虽然图中示意出其他规则引发的状态转换，但是实际上也是可以由其他规则引发，比如周期性的，或者接收到指示等等，与前述实施例中描述的内容相同，这里也不做赘述。
另一个实施例中，针对接收设备的一种解压缩处理方法，参见图2-2，包括以下处理步骤：
步骤31：接收到以太网数据；
步骤32：确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
所述有上下文状态包括以下至少之一：静态上下文状态、全部上下文状态。
这里需要说明的是，解压缩状态与前述状态可以对应，也可以有两种或三种，当解压缩状态有两种的时候，无上下文状态，还可以为不需解压缩状态，有上下文状态可以为需要解压缩状态。
另外，解压缩状态有三种的时候，可以包括有无上下文状态、静态上下文状态、全部上下文状态。其中，无上下文状态同样的可以为不需要解压缩状态，静态上下文状态可以为部分需要解压缩状态，全部上下文状态，可以为全部需要解压缩状态。
确定解压缩状态的处理可以包括确定状态是否变更。
确定解压缩状态的处理可以根据预设规则来进行，也就是与发送端对应的，针对压缩对应有解压缩的第二预设规则，具体可以包括：
基于第二预设规则，确定解压缩状态；
其中，所述第二预设规则包括以下至少之一：
基于周期，确定在不同解压缩状态之间进行状态转换；
基于定时器，确定在不同解压缩状态之间进行状态转换；
接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换；H为整数；
接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态；W为整数
接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；R为整数；其中，第一类型以及第二类型不同；
接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；Q为整数；其中，第三类型与第一类型以及第二类型不同；
接收到迁移指示时，基于所述迁移指示转换解压缩状态；
当在一个解压缩状态进行数据包解压缩失败时，转换至另一个解压缩状态；
在发送特定数据包或指示时，确定在不同解压缩状态之间进行状态转换。
具体来说，基于周期确定不同解压缩状态之间进行状态转换，可以为在处理过程中，可以基于预设的周期来确定在多个解压缩状态之间进行切换，进而可以确定当前所要使用的以太网数据包头的状态。比如，针对两种状态的时候，参见图4，针对无上下文状态、有上下文状态，基于在第一个周期中采用无上下文状态，在下一个周期采用有上下文状态，那么当前处于哪个周期，就可以确定当前数据包的解压缩状态为哪种。或者，针对三种状态的时候，也是可以根据当前的周期，确定解压缩状态为哪种。
基于定时器，确定在不同解压缩状态之间进行状态转换与上述类似，可以为针对不同的状态设置相同或不同的定时器，当定时器的时长达到对应的时长的时候，从一个解压缩状态转换至另一个解压缩状态，比如，针对有上下文状态的定时器时长达到之后，转换至无上下文状态，反之亦然。那么当前根据定时器确定处于哪种状态就控制所要发送的以太网数据包头处于哪种状态。
所述接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换；H为整数，包括以下之一：
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为有上下文状态；
接收或连续接收H个无上下文状态的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为静态上下文状态；
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为全部上下文状态；
接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为全部上下文状态；
接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为无上下文状态；
接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为静态上下文状态；
接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为无上下文状态。
需要指出的是，上述H个任意状态的数据包，可以理解为连续的接收H个其中某一个解压缩状态的数据包，或者是，不连续的接收H个某一个状态的解压缩状态的数据包。通常可能采用连续接收H个某一个状态的数据包的方式。
也就是说，在接收了多个其中一个解压缩状态的数据包的时候，转换至下一个解压缩状态，当原来的状态为无上下文状态时，当存在两种状态的时候，下一个状态可以为有上下文状态；当存在三种状态的时候，下一个状态可以为静态上下文状态，或者全部上下文状态。进一步地，当原来的状态为全部上下文状态的时候，下一个状态可以为静态上下文状态。或者，存在三种状态的时候，原来的状态为全部上下文状态，那么下一个状态为静态上下文状态或无上下文状态。在三种状态的时候下，还存在另一种情况，原来为静态上下文状态的时候，下一个状态可以为无上下文状态，还可以为全部上下文状态。具体可以根据预设协议来确定下一个状态具体是哪种。
在此基础上，本实施方式确定当前解压缩状态的方式，可以为基于当前接收的至少一个数据包的解压缩状态来判断，比如当前采用一个解压缩状态处理的数据包小于H个，那么仍然采用该解压缩状态进行处理，如果等于或大于H个，那么转换为采用另一个解压缩状态对以太网数据包头进行处理。
所述接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态，包括：
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为有上下文状态；
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为静态上下文状态；
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为全部上下文状态；
接收或连续接收到W个第一类型的数据包时，由静态上下文状态转换为全部上下文状态。
以及，所述接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态，包括：
接收或连续接收到R个第二类型的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由静态上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为静态上下文状态。
另外，还可以包括有接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态，包括：
接收或连续接收到Q个第三类型的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为无上下文状态；
接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为全部上下文状态。
这里需要指出的是，上述分支可以在不同情况下进行组合，也就是在不同情况下第一类型、第二类型以及第三类型的数据包可以不同。
比如，第一类型的数据包可以为无压缩状态的数据包，当接收到或者连续接收到多个第一类型的数据包的时候，可以认为压缩端会转换至压缩状态的数据包，那么相应的可以由无上下文状态转换至有上下文状态；或者，存在三种状态的时候，可以由无上下文状态转换为静态上下文状态，或者由无上下文状态转换至全部上下文状态。又或者，第一类型的数据包可以为无压缩状态的数据包，当接收到或者连续接收到多个第一类型的数据包的时候，可以认为压缩端会转换至非压缩状态的数据包，那么相应的可以由有上下文状态转换至无上下文状态；或者，存在三种状态的时候，可以由全部上下文状态转换为静态上下文状态，或者由全部上下文状态转换至无上下文状态。
又或者，第二类型的数据包可以理解为压缩状态的数据包，当接收到或连续接收到多个第二类型的数据包的时候，可以认为压缩端将会转换至非压缩状态，那么相应的，解压缩端需要将状态转换至无上下文状态。当存在三种解压缩状态的时候，可以认为压缩端可能会由压缩状态转换至部分数据压缩状态，相应的解压缩端可以将状态转换为静态上下文状态；或者，可以认为压缩端会转至非压缩状态，相应的，解压缩端将解压缩状态转换为全无上下文状态。
第三类型的数据包，可以理解为压缩端的部分数据压缩状态，当接受到或连续接收到多个第三类型的数据包的时候，可以认为压缩端将会转换至全部数据压缩状态，那么相应的，解压缩端需要将状态转换至全部上下文状态。或者，可以认为压缩端可能会转换至非压缩状态，相应的解压缩端可以将状态转换为无上下文状态。
关于接收到迁移指示时，基于所述迁移指示转换解压缩状态，可以为由发送端来指示接收端所要采用的解压缩状态，这种情况可以与发送端随动，也就是说，发送端根据自身的状态，指示接收到采用哪种解压缩状态进行处理。这种指示的发出时刻，可以为当发送端出现状态转换的时候发出，或者还可以为接收到发来请求信息的时候从反馈信息发出。或者，还可以为在每次发送数据的时候，随着数据发来相应的解压缩状态的指示。
上述当在一个解压缩状态进行数据包解压缩失败时，转换至另一个解压缩状态，可以理解为向更低的状态迁移，比如，当全部上下文解压缩失败的时候，可以转换至静态上下文状态进行加压缩，如果再失败，可以转换至无上下文状态。当然，还可以像高状态迁移，比如，当无上下文状态失败的时候，可以转换至静态上下文，或者还可以为全部上下文状态。
还需要说明的是，与发送端对应的，接收端会在发送或者连续发送多个确认信息的时候，也就是说连续的成功处理某一解压缩状态的数据包的时候，确定迁移解压缩状态，比如可以迁移至更高状态，比如，由无上下文状态，转换为全部上下文状态，或者，可以转换为静态上下文状态；或者，由静态上下文状态转换至全部上下文状态。
或者，接收端发送或连续发送多个非确认信息的时候，也就是说在某一个解压缩状态下失败处理多个数据包的时候，可以确定迁移解压缩状态，比如，可以迁移至更低状态，可以为，由有上下文状态转换至无上下文状态；或者，由全部上下文状态转换至静态上下文状态，或者由全部上下文状态转换至无上下文状态。还可以由静态上下文状态转换至无上下文状态。
图5示意出两种解压缩状态下，两个解压缩状态之间可以相互转换，当无上下文状态的定时器超时的时候，可以转换为有上下文状态，或者，无上下文状态下接收到或成功接收到多个数据包的时候，转换至有上下文状态，当然还可以为根据前述第二预设规则中的一个或多个规则的结合来控制状态转换。当处于有上下文状态的时候，可以为定时器超时，或者无法成功接收数据包，或者无法解压缩数据包的时候，转换至无上下文状态，同样的，也可以根据前述第二预设规则中的一个或多个规则的结合来控制状态转换，这里不再赘述。虽然图5只示意出两种状态的转换，实际上三种状态之间的转换类似的情况，只是不再示图表示。
下面以本发送端为终端设备进行上行数据发送、接收端为网络设备进行上行数据接收的情况为例提供多种场景的说明，具体的，后续的场景说明中，终端设备可以为用户设备(UE)，网络设备可以为网络侧的基站。需要理解的是，另外还可以存在的情况为发送端为网络设备、接收端为终端设备的时候，此时可以为进行下行数据发送以及接收的处理情况。无论是哪种设备作为发送端或解压缩端设备，处理方式是一样的，只是本实施例中不再穷举。
场景1、
参见图6，流程见下：
步骤41：基站配置针对以太网数据包的头压缩参数；通过RRC消息，进行配置数据传输，并给UE配置以太网数据包头压缩配置。也就是说，指示中可以包含有是否头压缩的指示，以及头压缩的方式；
步骤42：UE根据基站的指示，确认是否做头压缩，以及如何做头压缩。
其中，UE根据基站发送的以太网数据包头压缩配置信息，确定是否执行Ethernet头压缩，对哪个子头/子头类型进行头压缩等。
例如,可以仅对部分字段确定进行头压缩：目标地址DESTINATION ADDRESS,源地址SOURCE ADDRESS,类型或长度TYPE/LENGTH,虚拟网域Q-TAGs(including all sub-fields)；
又例如，对以太网数据包头中的静态或不变化的部分执行头压缩处理。具体进行头压缩的对象或者字段或者字段类型可以是协议协议中预先写好的，也可以是RRC配置中指示的。
可以将可压缩的字段进行分类：
静态字段类型，包括但不限于以下至少之一：DESTINATION ADDRESS,SOURCE ADDRESS，TYPE/LENGTH,Q-TAGs(including all sub-fields)；
可变字段类型，包括但不限于以下至少之一：TYPE，PRI/PCP，CFI/DEI。
需要指出的是，大多数情况下，可以认为可压缩的Ethernet头中的所有field都属于静态类型，如MAC地址，Q-Tags，Type/length。
步骤43：UE基于上述步骤，执行头压缩操作，其中还包括有状态迁移。
具体状态转换可选如下：
初始的头压缩状态为非压缩状态或IR状态。
在头压缩功能启动开始时，或者最初的时刻，UE(压缩端)处于非压缩状态或IR状态，UE发送未经压缩的Ethernet数据包。
需要指出的是，以太网数据包头的格式中携带的信息包括以下至少之一：太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示，序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
所述以太网数据包头的格式为：压缩状态的数据包以及非压缩状态的数据包采用不同格式；即独立的包格式，即不同的类型的包使用不同的包格式。如定义至少一种执行了以太网数据包头压缩的包的格式，一种非压缩(含有完整包信息)的Ethernet帧的包格式。和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。即统一的包格式，即压缩包和非压缩包(含有完整包信息)采用相同的包格式。
举例来说，不同状态的数据包格式例如图7、8所示，可以看出图7、8中针对压缩包类型的标识位的取值是不同的，以此来区分两种类型。其中，针对非压缩状态的格式参见图7，可以为“1111110D”或者为“11111110”；图8中的压缩状态的数据包格式中，针对其标识位的取值则为“11111000”，可以看出通过该标识位的取值就能够区分不同状态的数据包。
另外，不同状态的数据包格式还可以根据不同的格式来区分，仍然采用图7、8来示意。图7中示意出两种数据包的格式，均表示非压缩状态的数据包，可以看出，其中可以包含有动态链以及静态链，或者可以仅包含动态链；图8中，则看出压缩状态的数据包格式中，可以不包含静态连以及动态链，或者，包含静态连、动态链中的一个。
针对部分数据压缩状态以及全部数据压缩状态的数据包格式也可以不同，同样参见图8，其中，部分数据压缩状态的数据包的格式可以为图中左1，也就是包含有静态链，并且格式的标识位为“11111000”，或者为中间的格式，仅包含有动态链，同时标识位为“11111000”；而全部数据压缩状态的格式可以为不包含有静态链以及动态链，并且格式为“11111000”。
又或者，数据包的不同状态的以不同标识区分(即标识位的不同取值区分)，例如部分数据压缩状态的数据包的标识为“11111000”，全部数据压缩状态的数据包的标识为“11111100”，非压缩状态的数据包的标识为“11111110”。
还需要理解的是，前述两种针对格式的定义可以结合使用，比如，既可以存在格式上的不同，也可以在标识位上进行区分。如前所述，这里不再赘述。
将压缩包向下递交，进行PDCP层和/或RLC等层的处理。
步骤44：向基站发送压缩包。
在发送N个未经压缩的Ethernet数据包后，UE执行状态迁移，状态转移到压缩状态或CO状态。
当UE处于压缩状态或CO状态时，在定时器超时timeout后UE状态迁移到低压缩状态，即非压缩状态。
而后，循环执行上述步骤。可能的循环处理的方式可以参见图9，比如初始为未压缩态，那么发送N个未压缩态的数据包之后，可以转换为压缩态；进而可以结合定时器，定时器达到超时的时长的时候，转换为非压缩状态。
压缩端和解压缩端按照一定的规则，在这几个状态之间进行迁徙，完成头压缩和解压缩的操作。
基站作为解压缩端，对压缩包进行解压缩，而后将解压缩后的包向上递交，具体可 以包括：
步骤45：基站进行解压缩处理，其中包含有状态迁移。
具体的，基站在收到来自UE的压缩数据包后，按照相应的规则和映射关系，确定收到的包类型(是否压缩)，对未压缩的包进行上下文(Context)更新/存储，对收到的压缩包进行解压缩处理，并进行相应的状态迁徙。
具体状态转换可选如下：
初始的解压缩状态为No context状态。
在头压缩功能启动开始时，或者最初的时刻，基站(解压缩端)处于无上下文状态，基站接收到压缩端发送的未经压缩的Ethernet数据包后，对数据包按照不同的路径(context ID等)，进行context的更新或存储。
在收到N个未压缩的Ethernet数据包或者成功收到/解压缩N个未压缩的Ethernet数据包后，解压缩端执行状态迁移，迁移到高压缩状态，即存有context的状态，可以叫full context状态，或者static context状态。
当解压缩端，即基站，处于存有context的状态，可以叫full context状态，或者static context状态时，在timeout后基站状态迁移到低压缩状态，即No context状态。
而后，循环执行上述步骤。
本场景中，上述针对压缩端具备两种状态进行的说明，实际上还可以存在三种状态的迁移，比如：
压缩端在非压缩状态(IR状态)发送多个包后，迁移到部分数据压缩状态(FO状态)，在部分数据压缩状态(FO状态)发送多个包后迁移到全部数据压缩状态(SO状态)。在全部数据压缩状态(SO状态)中定时器超时回到部分数据压缩状态(FO状态)，在部分数据压缩状态(FO状态)定时器超时时回到非压缩状态(IR状态)。
相应的，解压缩端也可以针对三种状态进行处理，比如：
在无上下文状态收到成功解压缩多个包后，迁移到静态上下文状态，在静态上下文状态成功解压缩多个包后迁移到全部上下文状态。在全部上下文状态定时器超时timeout时回到静态上下文状态，在静态上下文状态timeout时回到无上下文状态。
需要说明的是，不同状态间的转换，可以采用相似的机制，也可以采用不同的机制，例如，可以均采用定时器方式。又例如，某些采用定时器机制，某些采用发送多个包的方式。这里不做限制。
需要说明的是，即使定义了三种状态，也可以仅使用其中的两种状态。
场景2、压缩端和解压缩端之间支持头压缩反馈包(反馈状态包)的传输，或者说，采用基于反馈的状态转移方式，使得压缩端和解压缩端的状态迁移可以依靠一种更为可靠或有效的方式执行。
以太网数据包包头压缩压缩端和/或解压缩端状态迁徙，基于反馈的状态转移方式
以太网数据包包头格式中携带的参数或标识信息，格式，状态等，具体内容同与前述相同，这里不再赘述。
以下仅对UL数据包的处理进行说明，下行包的头压缩处理与之类似。如图10所示，流程见下：
步骤51.基站配置针对以太网数据包头压缩参数，为UE进行配置数据传输并传输以太网数据包头压缩配置。比如，基站通过RRC消息，配置Ethernet frame信息头压缩的参数。
步骤52.UE根据基站的指示，确认是否做头压缩，以及如何做头压缩。
具体的，UE根据基站发送的Ethernet头压缩配置信息，确定是否执行Ethernet头压缩，对哪个子头/子头类型进行头压缩等。例如，对Ethernet头中的源地址，目标基站， Ethernet type，T-tags进行头压缩处理。例如，对Ethernet头中的静态或不变化的部分执行头压缩处理。具体进行头压缩的对象或者field或者field类型可以是协议协议中预先写好的，也可以是RRC配置中指示的。
步骤53.UE基于上述步骤，执行头压缩操作，其中包含状态迁移。
具体状态转换可选如下：
初始的头压缩状态为非压缩状态或IR状态。
可能的状态迁移图例如图11所示。比如，在头压缩功能启动开始时，或者最初的时刻，UE(压缩端)处于非压缩状态或IR状态，UE发送未经压缩的Ethernet数据包。在发送N个未经压缩的Ethernet数据包后，UE执行状态迁移，状态转移到压缩状态或CO状态。另外，在UE处于非压缩状态或IR状态的时候，UE发出N个非压缩状态的数据包、并且接收到解压缩端设备反馈的N个确认信息(ACK)时，进行状态迁移，比如可以迁移至压缩状态或CO状态；相应的，解压缩端，接收到、或者成功接收到、或者成功解压缩M个非压缩态数据包之后，才会向UE反馈M个确认信息，同时，解压缩端会向高状态迁移。其中，M和N不同，M可以小于N。
当UE处于压缩状态或CO状态时，在收到解压缩端发送的状态报告，且状态报告指示NACK状态后或者收到/Y个压缩包的NACK解压缩状态后，UE状态迁移到低压缩状态，即非压缩状态。另外，在UE处于压缩状态或CO状态的时候，UE发出Y个压缩状态的数据包、并且接收到解压缩端设备反馈的L个非确认信息(NACK)时，进行状态迁移，迁移至低压缩状态，比如可以非压缩状态；相应的，解压缩端，无法接收到、或者无法成功解压缩L个压缩态数据包，会向UE反馈L个非确认信息(NACK)，同时，解压缩端会向低状态迁移。其中，L和Y可以不同，比如L可以小于Y。
而后，循环执行上述步骤。
UE将压缩包向下递交，进行PDCP层和/或RLC等层的处理。
步骤54.发送压缩后的数据包至基站。
基站作为解压缩端，对压缩包进行解压缩，而后将解压缩后的包向上递交
步骤55.基站进行解压缩处理，处理过程中还包括状态迁移处理。
步骤56.基站向UE发送反馈包。
具体来说，基站在收到来自UE的压缩数据包后，按照相应的规则和映射关系，确定收到的包类型(是否压缩)，对未压缩的包进行context更新/存储，对收到的压缩包进行解压缩处理，并进行相应的状态迁徙。
具体状态转换可选如下：
初始的解压缩状态为No context状态。
比如，参见图12，在头压缩功能启动开始时，或者最初的时刻，基站(解压缩端)处于无No context状态，基站接收到压缩端发送的未经压缩的Ethernet数据包后，对数据包按照不同的路径(context ID等)，进行context的更新或存储。
在收到N个未压缩的Ethernet数据包或者成功收到/解压缩N个未压缩的Ethernet数据包后，解压缩端执行状态迁移，迁移到高压缩状态，即存有context的状态，可以叫full context状态，或者static context状态。
当解压缩端，即基站，处于存有context的状态，可以叫full context状态，或者static context状态时，当解压缩到Y个压缩包的NACK解压缩状态后，或者，发送Ethenet状态报告，且状态报告中携带NACK状态后，基站状态迁移到低压缩状态，即No context状态。
而后，循环执行上述步骤。
还需要指出的是，前述针对了两种压缩状态以及解压缩状态进行的说明，实际上还 可以为压缩端存在三种状态，三种状态迁移例如如下：
压缩端在非压缩状态(IR状态)发送N个包后，迁移到部分数据压缩状态(FO状态)，在部分数据压缩状态(FO状态)发送N个包后迁移到全部数据压缩状态(SO状态)。
相应的，解压缩端也可以针对三种状态进行处理，比如：
在无上下文状态收到成功解压缩多个包后，迁移到静态上下文状态，在静态上下文状态成功解压缩多个包后迁移到全部上下文状态。在全部上下文状态状态发送第一类NACK时回到静态上下文状态，在静态上下文状态发送第一类NACK时回到无上下文状态。
需要说明的是，不同状态间的转换，可以采用相似的机制，也可以采用不同的机制，例如，可以均采用定时器方式。又例如，一些状态的转换根据指示信息来进行，另一些转换可以根据接收到的NACK或者ACK来确定进行转换，这里不进行穷举。
可见，通过采用上述方案，能够在发送以及接受以太网数据包的时候，针对数据包头进行压缩，并根据不同的状态确定当前需要采用哪种方式进行压缩或解压缩。从而解决了如何使用以太网数据包头压缩的问题，同时减少了空口的资源开销。
本申请实施例提供了一种压缩端设备，如图13所示，包括：
第一处理单元61，确定所要发送的以太网数据包头的状态；
基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
本实施例可以应用于发送设备，比如可以为终端设备或者可以为网络设备，只要需要进行数据发送的设备均可以为本实施例所述的发送设备。
本实施例中压缩状态可以包括有压缩以及未压缩两种情况；或者，压缩状态还可以理解为：包括初始化状态、和更新状态IR(initialization and Refresh)即非压缩状态。
或者，所述压缩状态包括以下至少之一：部分数据压缩状态、全部数据压缩状态。
也就是说，本实施例中可以存在压缩状态以及非压缩状态这两种情况；也可以存在非压缩状态、部分数据压缩状态以及全部数据压缩状态这三种情况。或者，可以分别称为：初始化、和更新状态IR(initialization and Refresh)，中间状态FO(First order)和最高状态SO(Second order)。其中，最高状态SO(Second order)可以为全部数据压缩状态，中间状态可以为部分数据压缩状态。
需要理解的是，还可以包括：第一通信单元，发送包含有处理后的以太网数据包头的所述以太网数据包。
第一处理单元61确定所要发送的以太网数据包头的状态，包括：确定状态是否变更，确定所要发送的以太网数据包头的状态。
具体的可以包括：
基于第一预设规则，确定所要发送的以太网数据包头的状态；
其中，所述第一预设规则包括以下至少之一：
基于周期，确定在不同状态之间进行状态转换；
基于定时器，确定在不同状态之间进行状态转换；
发送N个在同一个状态的以太网数据包头的数据包，向另一个压缩状态转换；N为整数；
接收到确认信息时，由一个状态转换为另一个状态；
接收到非确认信息时，由一个状态转换为另一个状态；
接收到特定指示时，由一个状态转换为另一个状态。
也就是说，可以基于第一预设规则，来确定当前所要发送的以太网数据包头的压缩状态。
需要说明的是，在下述描述中，是按照头压缩的不同效率(从低到高)来从前到后给出头压缩状态的命名，代表了初始化状态，中间状态和/或完全状态。
所述第一处理单元61，包括以下之一：
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为压缩状态；
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为部分数据压缩状态；
发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为全部数据压缩状态；
发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为全部数据压缩状态；
发送N个压缩状态的以太网数据包头的数据包时，由压缩状态转换为非压缩状态；
发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为非压缩状态；
发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为部分数据压缩状态；
发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为非压缩状态。
需要指出的是，上述发送N个某个状态的数据包，可以理解为连续的发送N个其中某一个状态的数据包，或者是，不连续的发送N个某一个状态的数据包。通常可能采用连续发送N个某一个状态的数据包的方式。
也就是说，在发送了多个其中一个状态的数据包的时候，转换至下一个状态，当原来的状态为非压缩状态时，当存在两种状态的时候，下一个状态可以为压缩状态，当存在三种状态的时候，下一个状态可以为部分数据压缩状态，或者全部数据压缩状态。进一步地，当原来的状态为压缩状态的时候，下一个状态可以为非压缩状态。或者，存在三种状态的时候，原来的状态为全部数据压缩状态，那么下一个状态为部分数据压缩状态或非压缩状态。在三种状态的时候下，还存在另一种情况，原来为部分数据压缩状态的时候，下一个状态可以为全部数据压缩状态，还可以为非压缩状态。具体可以根据预设协议来确定下一个状态具体是哪种。
在此基础上，本实施方式确定当前所要发送的以太网数据包头的状态的方式，可以为基于当前已经发送的至少一个以太网数据包中数据包头的状态来判断，比如当前采用一个状态发送的数据包小于N个，那么仍然采用该状态发送当前的所要发送的以太网数据包，如果等于N个，那么转换为采用另一个状态对以太网数据包头进行处理并发送以太网数据包。
所述第一处理单元61，包括以下之一：
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为部分数据压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由部分数据压缩状态转换为全部数据压缩状态；
接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为全部数据压缩状态；
M和C均为大于等于1的整数。
其中，M个C可以相同也可以不同，比如，可以为M小于C，也就是说，当判断连续接收的时候，可以较少的数量就能够确定是否进行状态转换；当非连续接收确认信息的时候，也就是中间可能存在非确认信息，那么此时可以多收几个非连续的确认信息再确定状态转换。当然，反之也可以，比如M大于C，具体的可以根据双方协议来确定。
前述第一处理单元61，包括以下之一：
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为非压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由压缩状态转换为非压缩状态；
K和L为大于等于1的整数。
其中，K和L可以相同也可以不同。
所述第一处理单元61，包括以下至少之一：
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；A、F为大于等于1的整数；
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由全部数据压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由压缩状态转换为非压缩状态；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由全部数据压缩状态转换为非压缩状态；G和P均为整数；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由部分数据压缩状态转换为非压缩状态；
接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由压缩状态转换为非压缩状态；
其中，所述第一类非确认信息、第二类非确认信息以及第三类非确认信息均不相同。
这里需要指出的是，上述分支可以在不同情况下进行组合，也就是在不同情况下第一类、第二类以及第三类非确认信息可以不同。
另一个实施例中，一种解压缩端设备，参见图14，包括：
第二通信单元71，接收到以太网数据；
第二处理单元72，确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
所述有上下文状态包括以下至少之一：静态上下文状态、全部上下文状态。
这里需要说明的是，解压缩状态与前述状态可以对应，也可以有两种或三种，当解压缩状态有两种的时候，无上下文状态，还可以为不需解压缩状态，有上下文状态可以为需要解压缩状态。
另外，解压缩状态有三种的时候，可以包括有无上下文状态、静态上下文状态、全部上下文状态。其中，无上下文状态同样的可以为不需要解压缩状态，静态上下文状态可以为部分需要解压缩状态，全部上下文状态，可以为全部需要解压缩状态。
确定解压缩状态的处理可以包括确定状态是否变更。
确定解压缩状态的处理可以根据预设规则来进行，也就是与发送端对应的，针对压缩对应有解压缩的第二预设规则，具体可以包括：
基于第二预设规则，确定解压缩状态；
其中，所述第二预设规则包括以下至少之一：
基于周期，确定在不同解压缩状态之间进行状态转换；
基于定时器，确定在不同解压缩状态之间进行状态转换；
接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换；H为整数；
接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态；W为整数
接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；R为整数；其中，第一类型以及第二类型不同；
接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；Q为整数；其中，第三类型与第一类型以及第二类型不同；
接收到迁移指示时，基于所述迁移指示转换解压缩状态；
当在一个解压缩状态进行数据包解压缩失败时，转换至另一个解压缩状态；
在发送特定数据包或指示时，确定在不同解压缩状态之间进行状态转换。
具体来说，基于周期确定不同解压缩状态之间进行状态转换，可以为在处理过程中，可以基于预设的周期来确定在多个解压缩状态之间进行切换，进而可以确定当前所要使用的以太网数据包头的状态。比如，针对两种状态的时候，参见图4，针对无上下文状态、有上下文状态，基于在第一个周期中采用无上下文状态，在下一个周期采用有上下文状态，那么当前处于哪个周期，就可以确定当前数据包的解压缩状态为哪种。或者，针对三种状态的时候，也是可以根据当前的周期，确定解压缩状态为哪种。
基于定时器，确定在不同解压缩状态之间进行状态转换与上述类似，可以为针对不同的状态设置相同或不同的定时器，当定时器的时长达到对应的时长的时候，从一个解压缩状态转换至另一个解压缩状态，比如，针对有上下文状态的定时器时长达到之后，转换至无上下文状态，反之亦然。那么当前根据定时器确定处于哪种状态就控制所要发送的以太网数据包头处于哪种状态。
所述第二处理单元72，包括以下之一：
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为有上下文状态；
接收或连续接收H个无上下文状态的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为静态上下文状态；
接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为全部上下文 状态；
接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为全部上下文状态；
接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为无上下文状态；
接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为静态上下文状态；
接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为无上下文状态。
需要指出的是，上述H个任意状态的数据包，可以理解为连续的接收H个其中某一个解压缩状态的数据包，或者是，不连续的接收H个某一个状态的解压缩状态的数据包。通常可能采用连续接收H个某一个状态的数据包的方式。
所述第二处理单元72，包括：
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为有上下文状态；
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为静态上下文状态；
接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为全部上下文状态；
接收或连续接收到W个第一类型的数据包时，由静态上下文状态转换为全部上下文状态。
以及，所述第二处理单元72，包括：
接收或连续接收到R个第二类型的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由静态上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为无上下文状态；
接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为静态上下文状态。
另外，第二处理单元72，包括：
接收或连续接收到Q个第三类型的数据包时，由有上下文状态转换为无上下文状态；
接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为无上下文状态；
接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为全部上下文状态。
需要指出的是，以太网数据包头的格式中携带的信息包括以下至少之一：太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示，序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
所述以太网数据包头的格式为：压缩状态的数据包以及非压缩状态的数据包采用不同格式；即独立的包格式，即不同的类型的包使用不同的包格式。如定义至少一种执行了以太网数据包头压缩的包的格式，一种非压缩(含有完整包信息)的Ethernet帧的包格式。和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。即统一的包格式，即压缩包和非压缩包(含有完整包信息)采用相同的包格式。
举例来说，不同状态的数据包格式例如图7、8所示，可以看出图7、8中针对压缩包类型的标识位的取值是不同的，以此来区分两种类型。其中，针对非压缩状态的格式参见图7，可以为“1111110D”或者为“11111110”；图8中的压缩状态的数据包格式中，针对其标识位的取值则为“11111000”，可以看出通过该标识位的取值就能够区分不同状态的数据包。
另外，不同状态的数据包格式还可以根据不同的格式来区分，仍然采用图7、8来示意。图7中示意出两种数据包的格式，均表示非压缩状态的数据包，可以看出，其中可以包含有动态链以及静态链，或者可以仅包含动态链；图8中，则看出压缩状态的数据包格式中，可以不包含静态连以及动态链，或者，包含静态连、动态链中的一个。
针对部分数据压缩状态以及全部数据压缩状态的数据包格式也可以不同，同样参见图8，其中，部分数据压缩状态的数据包的格式可以为图中左1，也就是包含有静态链，并且格式的标识位为“11111000”，或者为中间的格式，仅包含有动态链，同时标识位为“11111000”；而全部数据压缩状态的格式可以为不包含有静态链以及动态链，并且格式为“11111000”。又或者，数据包的不同状态的以不同标识区分(即标识位的不同取值区分)，例如部分数据压缩状态的数据包的标识为“11111000”，全部数据压缩状态的数据包的标识为“11111100”，非压缩状态的数据包的标识为“11111110”。
还需要理解的是，前述两种针对格式的定义可以结合使用，比如，既可以存在格式上的不同，也可以在标识位上进行区分。如前所述，这里不再赘述。
可见，通过采用上述方案，能够在发送以及接受以太网数据包的时候，针对数据包头进行压缩，并根据不同的状态确定当前需要采用哪种方式进行压缩或解压缩。从而解决了如何使用以太网数据包头压缩的问题，同时减少了空口的资源开销。
图15是本申请实施例提供的一种通信设备800示意性结构图，通信设备可以为本实施例前述的终端设备或者网络设备。图16所示的通信设备800包括处理器810，处理器810可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图15所示，通信设备800还可以包括存储器820。其中，处理器810可以从存储器820中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器820可以是独立于处理器810的一个单独的器件，也可以集成在处理器810中。
可选地，如图15所示，通信设备800还可以包括收发器830，处理器810可以控制该收发器830与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。
其中，收发器830可以包括发射机和接收机。收发器830还可以进一步包括天线，天线的数量可以为一个或多个。
可选地，该通信设备800具体可为本申请实施例的压缩端设备或解压缩端设备，并且该通信设备800可以实现本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
图16是本申请实施例的芯片的示意性结构图。图16所示的芯片900包括处理器910，处理器910可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图16所示，芯片900还可以包括存储器920。其中，处理器910可以从存储器920中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器920可以是独立于处理器910的一个单独的器件，也可以集成在处理器910中。
可选地，该芯片900还可以包括输入接口930。其中，处理器910可以控制该输入接口930与其他设备或芯片进行通信，具体地，可以获取其他设备或芯片发送的信息或 数据。
可选地，该芯片900还可以包括输出接口940。其中，处理器910可以控制该输出接口940与其他设备或芯片进行通信，具体地，可以向其他设备或芯片输出信息或数据。
可选地，该芯片可应用于本申请实施例中的压缩端设备或解压缩端设备，并且该芯片可以实现本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
图17是本申请实施例提供的一种通信系统1000的示意性框图。如图17所示，该通信系统1000包括压缩端设备1010和解压缩端设备1020。
其中，该压缩端设备1010可以用于实现上述方法中由终端设备实现的相应的功能，以及该解压缩端设备1020可以用于实现上述方法中由网络设备实现的相应的功能为了简洁，在此不再赘述。
应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
应理解，上述存储器为示例性但不是限制性说明，例如，本申请实施例中的存储器还可以是静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)以及直接内存总线随机存取存储器(Direct Rambus RAM， DR RAM)等等。也就是说，本申请实施例中的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。
可选的，该计算机可读存储介质可应用于本申请实施例中的网络设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机可读存储介质可应用于本申请实施例中的终端设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序产品，包括计算机程序指令。
可选的，该计算机程序产品可应用于本申请实施例中的网络设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序产品可应用于本申请实施例中的移动终端/终端设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序。
可选的，该计算机程序可应用于本申请实施例中的网络设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序可应用于本申请实施例中的移动终端/终端设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说 对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，)ROM、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (43)

  1. 一种压缩处理方法，包括：
    确定所要发送的以太网数据包头的状态，
    基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
    其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
  2. 根据权利要求1所述的方法，其中，所述压缩状态包括以下至少之一：部分数据压缩状态、全部数据压缩状态。
  3. 根据权利要求1或2所述的方法，其中，确定所要发送的以太网数据包头的状态，包括：
    基于第一预设规则，确定所要发送的以太网数据包头的状态；
    其中，所述第一预设规则包括以下至少之一：
    基于周期，确定在不同状态之间进行状态转换；
    基于定时器，确定在不同状态之间进行状态转换；
    发送N个在同一个状态的以太网数据包头的数据包，向另一个压缩状态转换；N为整数；
    接收到确认信息时，由一个状态转换为另一个状态；
    接收到非确认信息时，由一个状态转换为另一个状态；
    接收到特定指示时，由一个状态转换为另一个状态。
  4. 根据权利要求3所述的方法，其中，所述发送N个在同一个状态的以太网数据包头的数据包，向另一个压缩状态转换，包括以下至少之一：
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为压缩状态；
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为部分数据压缩状态；
    发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为全部数据压缩状态；
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为全部数据压缩状态；
    发送N个压缩状态的以太网数据包头的数据包时，由压缩状态转换为非压缩状态；
    发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为非压缩状态；
    发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为部分数据压缩状态；
    发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为非压缩状态。
  5. 根据权利要求3所述的方法，其中，所述接收到确认信息时，由一个状态转换为另一个状态，包括以下至少之一：
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为部分数据压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由部分数据压缩状态转换为全部数据压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为全部数据压缩状态；
    M和C均为大于等于1的整数。
  6. 根据权利要求3所述的方法，其中，接收到非确认信息时，由一个压缩状态转换为另一个压缩状态，包括以下至少之一：
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为非压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由压缩状态转换为非压缩状态；
    K和L为大于等于1的整数。
  7. 根据权利要求3所述的方法，其中，所述接收到非确认信息时，由一个状态转换为另一个状态，包括以下至少之一：
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；A、F为大于等于1的整数；
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由全部数据压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由压缩状态转换为非压缩状态；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由全部数据压缩状态转换为非压缩状态；G和P均为整数；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由压缩状态转换为非压缩状态；
    其中，所述第一类非确认信息、第二类非确认信息以及第三类非确认信息均不相同。
  8. 根据权利要求1-7任一项所述的方法，其中，以太网数据包头的格式中携带的信息包括以下至少之一：
    太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示，序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
  9. 根据权利要求8所述的方法，其中，所述以太网数据包头的格式为：
    压缩状态的数据包以及非压缩状态的数据包采用不同格式；
    和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。
  10. 一种解压缩处理方法，包括：
    接收到以太网数据；
    确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
    其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
  11. 根据权利要求10所述的方法，其中，所述有上下文状态包括以下至少之一：静态上下文状态、全部上下文状态。
  12. 根据权利要求10或11所述的方法，其中，确定解压缩状态，包括：
    基于第二预设规则，确定解压缩状态；
    其中，所述第二预设规则包括以下至少之一：
    基于周期，确定在不同解压缩状态之间进行状态转换；
    基于定时器，确定在不同解压缩状态之间进行状态转换；
    接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换；H为整数；
    接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态；W为整数
    接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；R为整数；其中，第一类型以及第二类型不同；
    接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；Q为整数；其中，第三类型与第一类型以及第二类型不同；
    接收到迁移指示时，基于所述迁移指示转换解压缩状态；
    当在一个解压缩状态进行数据包解压缩失败时，转换至另一个解压缩状态。
  13. 根据权利要求12所述的方法，其中，所述接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换，包括以下至少之一：
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为有上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为静态上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为全部上下文状态；
    接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为全部上下文状态；
    接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为无上下文状态；
    接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为静态上下文状态；
    接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为无上下文状态。
  14. 根据权利要求12所述的方法，其中，所述接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态，包括以下至少之一：
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为有上下文状态；
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为静态上下文状态；
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为全部上下文状态；
    接收或连续接收到W个第一类型的数据包时，由静态上下文状态转换为全部上下文状态。
  15. 根据权利要求14所述的方法，其中，所述接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态，包括以下至少之一：
    接收或连续接收到R个第二类型的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由静态上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为静态上下文状态。
  16. 根据权利要求14所述的方法，其中，所述接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态，包括以下至少之一：
    接收或连续接收到Q个第三类型的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为无上下文状态；
    接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为全部上下文状态。
  17. 根据权利要求10-16任一项所述的方法，其中，以太网数据包头的格式中携带的信息包括以下至少之一：
    太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示，序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
  18. 根据权利要求17所述的方法，其中，所述以太网数据包头的格式为：
    压缩状态的数据包以及非压缩状态的数据包采用不同格式；
    和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。
  19. 一种压缩端设备，包括：
    第一处理单元，确定所要发送的以太网数据包头的状态，基于所述所要发送的以太网数据包头的状态，对所述所要发送的以太网数据包头的数据进行处理；
    其中，所述以太网数据包头的状态包括以下至少之一：非压缩状态、压缩状态。
  20. 根据权利要求19所述的压缩端设备，其中，所述压缩状态包括以下至少之一：部分数据压缩状态、全部数据压缩状态。
  21. 根据权利要求19或20所述的压缩端设备，其中，第一处理单元，基于第一预设规则，确定所要发送的以太网数据包头的状态；
    其中，所述第一预设规则包括以下至少之一：
    基于周期，确定在不同状态之间进行状态转换；
    基于定时器，确定在不同状态之间进行状态转换；
    发送N个在同一个状态的以太网数据包头的数据包，向另一个压缩状态转换；N为整数；
    接收到确认信息时，由一个状态转换为另一个状态；
    接收到非确认信息时，由一个状态转换为另一个状态；
    接收到特定指示时，由一个状态转换为另一个状态。
  22. 根据权利要求21所述的压缩端设备，其中，所述第一处理单元，执行以下至少之一：
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为压缩状态；
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为部分数据压缩状态；
    发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为全部数据压缩状态；
    发送N个非压缩状态的以太网数据包头的数据包时，由非压缩状态转换为全部数据压缩状态；
    发送N个压缩状态的以太网数据包头的数据包时，由压缩状态转换为非压缩状态；
    发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为非压缩状态；
    发送N个全部数据压缩状态的以太网数据包头的数据包时，由全部数据压缩状态转换为部分数据压缩状态；
    发送N个部分数据压缩状态的以太网数据包头的数据包时，由部分数据压缩状态转换为非压缩状态。
  23. 根据权利要求21所述的压缩端设备，其中，所述第一处理单元，执行以下至少之一：
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为部分数据压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由部分数据压缩状态转换为全部数据压缩状态；
    接收连续M个确认信息，或者，接收到C个确认信息时，由非压缩状态转换为全部数据压缩状态；
    M和C均为大于等于1的整数。
  24. 根据权利要求21所述的压缩端设备，其中，所述第一处理单元，执行以下至少之一：
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由全部数据压缩状态转换为非压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到连续的K个非确认信息时，或者，接收到L个非确认信息时，由压缩状态转换为非压缩状态；
    K和L为大于等于1的整数。
  25. 根据权利要求21所述的压缩端设备，其中，所述第一处理单元，执行以下至少之一：
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由全部数据压缩状态转换为部分数据压缩状态；A、F为大于等于1的整数；
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到A个第一类非确认信息、或者接收到连续的F个第一类非确认信息时，由压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由全部数据压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到B个第二类非确认信息、或者接收到连续的E个第二类非确认信息时，由压缩状态转换为非压缩状态；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由全部数据压缩状态转换为非压缩状态；G和P均为整数；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由部分数据压缩状态转换为非压缩状态；
    接收到G个第三类非确认信息、或者接收到连续的P个第三类非确认信息时，由压缩状态转换为非压缩状态；
    其中，所述第一类非确认信息、第二类非确认信息以及第三类非确认信息均不相同。
  26. 根据权利要求19-25任一项所述的压缩端设备，其中，以太网数据包头的格式中携带的信息包括以下至少之一：
    太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示,序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
  27. 根据权利要求26所述的压缩端设备，其中，所述以太网数据包头的格式为：
    压缩状态的数据包以及非压缩状态的数据包采用不同格式；
    和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。
  28. 一种解压缩端设备，包括：
    第二通信单元，接收到以太网数据；
    第二处理单元，确定解压缩状态，基于所述解压缩状态，对所述以太网数据包头的数据进行处理；
    其中，所述解压缩状态包括以下至少之一：无上下文状态、有上下文状态。
  29. 根据权利要求28所述的解压缩端设备，其中，所述有上下文状态包括以下至少之一：静态上下文状态、全部上下文状态。
  30. 根据权利要求28或29所述的解压缩端设备，其中，第二处理单元，基于第二预设规则，确定解压缩状态；
    其中，所述第二预设规则包括以下至少之一：
    基于周期，确定在不同解压缩状态之间进行状态转换；
    基于定时器，确定在不同解压缩状态之间进行状态转换；
    接收或连续接收H个在同一个解压缩状态下数据包，向另一个解压缩状态转换；H为整数；
    接收或连续接收到W个第一类型的数据包，由一个解压缩状态转换为另一个解压缩状态；W为整数
    接收或连续接收到R个第二类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；R为整数；其中，第一类型以及第二类型不同；
    接收或连续接收到Q个第三类型的数据包时，由一个解压缩状态转换为另一个解压缩状态；Q为整数；其中，第三类型与第一类型以及第二类型不同；
    接收到迁移指示时，基于所述迁移指示转换解压缩状态；
    当在一个解压缩状态进行数据包解压缩失败时，转换至另一个解压缩状态。
  31. 根据权利要求30所述的解压缩端设备，其中，第二处理单元，执行以下至少之一：
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为有上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为静态上下文状态；
    接收或连续接收H个无上下文状态的数据包时，由无上下文状态转换为全部上下文状态；
    接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为全部上下文状态；
    接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为无上下文状态；
    接收或连续接收H个全部上下文状态的数据包时，由全部上下文状态转换为静态上下文状态；
    接收或连续接收H个静态上下文状态的数据包时，由静态上下文状态转换为无上下文状态。
  32. 根据权利要求30所述的解压缩端设备，其中，第二处理单元，执行以下至少之一：
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为有上下文状态；
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为静态上下文状态；
    接收或连续接收到W个第一类型的数据包时，由无上下文状态转换为全部上下文状态；
    接收或连续接收到W个第一类型的数据包时，由静态上下文状态转换为全部上下文状态。
  33. 根据权利要求30所述的解压缩端设备，其中，第二处理单元，执行以下至少之一：
    接收或连续接收到R个第二类型的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由静态上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为无上下文状态；
    接收或连续接收到R个第二类型的数据包时，由全部上下文状态转换为静态上下文状态。
  34. 根据权利要求30所述的解压缩端设备，其中，第二处理单元，执行以下至少之一：
    接收或连续接收到Q个第三类型的数据包时，由有上下文状态转换为无上下文状态；
    接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为无上下文状态；
    接收或连续接收到Q个第三类型的数据包时，由静态上下文状态转换为全部上下文 状态。
  35. 根据权利要求28-34任一项所述的解压缩端设备，其中，以太网数据包头的格式中携带的信息包括以下至少之一：
    太网数据包帧头压缩标识，上下文标识，校验序列/标识FCS，是否头压缩的指示，序列号SN，循环冗余码校验CRC，不压缩的域/子头标识，不压缩的域/子头指示。
  36. 根据权利要求35所述的解压缩端设备，其中，所述以太网数据包头的格式为：
    压缩状态的数据包以及非压缩状态的数据包采用不同格式；
    和/或，压缩状态的数据包以及非压缩状态的数据包采用相同格式，且压缩状态的数据包以及非压缩状态的数据包的至少一个标识位中取值不同。
  37. 一种压缩端设备，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，
    其中，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求1-9任一项所述方法的步骤。
  38. 一种解压缩端设备，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，
    其中，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求10-18任一项所述方法的步骤。
  39. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求1-9中任一项所述的方法。
  40. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求10-18中任一项所述的方法。
  41. 一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1-18任一项所述方法的步骤。
  42. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求1-18中任一项所述的方法。
  43. 一种计算机程序，所述计算机程序使得计算机执行如权利要求1-18中任一项所述的方法。
PCT/CN2019/080654 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备 WO2020199030A1 (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN202110944902.0A CN113709812B (zh) 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备
JP2021557688A JP2022532020A (ja) 2019-03-29 2019-03-29 圧縮処理方法、解圧縮処理方法及び関連機器
CN201980079482.5A CN113228582A (zh) 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备
PCT/CN2019/080654 WO2020199030A1 (zh) 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备
KR1020217035244A KR20210141734A (ko) 2019-03-29 2019-03-29 압축 처리 방법, 압축 해제 처리 방법 및 관련 기기
EP19922297.7A EP3905626B1 (en) 2019-03-29 2019-03-29 Compression processing method, decompression processing method and related devices
US17/411,622 US11671870B2 (en) 2019-03-29 2021-08-25 Compression processing method, decompression processing method and related devices

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/080654 WO2020199030A1 (zh) 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/411,622 Continuation US11671870B2 (en) 2019-03-29 2021-08-25 Compression processing method, decompression processing method and related devices

Publications (1)

Publication Number Publication Date
WO2020199030A1 true WO2020199030A1 (zh) 2020-10-08

Family

ID=72664385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/080654 WO2020199030A1 (zh) 2019-03-29 2019-03-29 一种压缩处理方法、解压缩处理方法及相关设备

Country Status (6)

Country Link
US (1) US11671870B2 (zh)
EP (1) EP3905626B1 (zh)
JP (1) JP2022532020A (zh)
KR (1) KR20210141734A (zh)
CN (2) CN113709812B (zh)
WO (1) WO2020199030A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022151105A1 (zh) * 2021-01-13 2022-07-21 北京小米移动软件有限公司 一种压缩处理方法及装置
CN115484312A (zh) * 2021-05-31 2022-12-16 展讯通信（上海）有限公司 以太网包头压缩方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453298A (zh) * 2007-12-07 2009-06-10 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
CN102025737A (zh) * 2010-12-09 2011-04-20 中兴通讯股份有限公司 微波通信中以太网数据包压缩、传输方法和压缩机、系统
CN103369593A (zh) * 2012-04-05 2013-10-23 中兴通讯股份有限公司 一种压缩和解压缩以太网报文的方法及网元设备
CN103825869A (zh) * 2012-11-19 2014-05-28 中兴通讯股份有限公司 以太网报文头的压缩及解压缩方法、压缩及解压缩设备

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668545B2 (en) * 2003-10-03 2010-02-23 Qualcomm Incorporated Maintaining data connectivity for handoffs between compression-enabled and compression-disabled communication systems
IL162305A (en) * 2004-06-02 2010-06-16 Eci Telecom Ltd Method, device and system for transmitting ethernet packets
US7817628B2 (en) * 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic
JP4694913B2 (ja) 2004-11-22 2011-06-08 アレコント ビジョン，リミティド ライアビリティ カンパニー 画像処理、圧縮及びネットワークサーバの大きな並列実行を有する高解像度ネットワークカメラ
JP4167702B2 (ja) * 2006-06-21 2008-10-22 Ｎｅｃアクセステクニカ株式会社 無線ｌａｎシステム、通信装置、圧縮処理の自動最適化方法
WO2008126764A1 (ja) * 2007-04-05 2008-10-23 Sharp Kabushiki Kaisha 通信方式決定装置、送信装置、受信装置、ｏｆｄｍ適応変調システムおよび通信方式決定方法
EP2174462A1 (en) * 2007-07-05 2010-04-14 Ceragon Networks LTD. Data packet header compression
US9515925B2 (en) 2011-05-19 2016-12-06 Qualcomm Incorporated Apparatus and methods for media access control header compression
US9176858B2 (en) * 2012-11-19 2015-11-03 Hitachi, Ltd. Storage system configured to selectively utilize data compression based on real pool usage rates
US9485687B2 (en) * 2013-02-15 2016-11-01 Exalt Wireless, Inc. Selective compression in a wireless communication system
CN106416356A (zh) * 2015-05-20 2017-02-15 华为技术有限公司 上行数据包处理方法、装置和基站
KR20230003630A (ko) * 2015-06-29 2023-01-06 주식회사 윌러스표준기술연구소 레거시 무선 통신 단말과 공존을 위한 무선 통신 방법 및 무선 통신 단말
CN107104813B (zh) * 2016-02-23 2020-08-07 华为技术有限公司 一种信息传输方法、网关及控制器
EP3419238B1 (en) * 2016-03-14 2020-05-06 Huawei Technologies Co., Ltd. Method, apparatus, and system for transmitting data
US11218966B2 (en) * 2017-10-27 2022-01-04 Wilus Institute Of Standards And Technology Inc. Wireless communication method and wireless communication terminal using wake-up radio
WO2019182420A1 (ko) * 2018-03-22 2019-09-26 주식회사 윌러스표준기술연구소 가변 길이의 웨이크-업 프레임을 이용하는 무선 통신 방법 및 무선 통신 단말

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453298A (zh) * 2007-12-07 2009-06-10 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
CN102025737A (zh) * 2010-12-09 2011-04-20 中兴通讯股份有限公司 微波通信中以太网数据包压缩、传输方法和压缩机、系统
CN103369593A (zh) * 2012-04-05 2013-10-23 中兴通讯股份有限公司 一种压缩和解压缩以太网报文的方法及网元设备
CN103825869A (zh) * 2012-11-19 2014-05-28 中兴通讯股份有限公司 以太网报文头的压缩及解压缩方法、压缩及解压缩设备

Non-Patent Citations (1)

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

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022151105A1 (zh) * 2021-01-13 2022-07-21 北京小米移动软件有限公司 一种压缩处理方法及装置
CN115136571A (zh) * 2021-01-13 2022-09-30 北京小米移动软件有限公司 一种压缩处理方法及装置
CN115136571B (zh) * 2021-01-13 2024-10-01 北京小米移动软件有限公司 一种压缩处理方法及装置
CN115484312A (zh) * 2021-05-31 2022-12-16 展讯通信（上海）有限公司 以太网包头压缩方法及装置
CN115484312B (zh) * 2021-05-31 2024-05-17 展讯通信（上海）有限公司 以太网包头压缩方法及装置

Also Published As

Publication number Publication date
CN113709812A (zh) 2021-11-26
CN113228582A (zh) 2021-08-06
EP3905626A1 (en) 2021-11-03
US11671870B2 (en) 2023-06-06
EP3905626B1 (en) 2022-12-28
EP3905626A4 (en) 2022-01-19
KR20210141734A (ko) 2021-11-23
CN113709812B (zh) 2023-03-24
JP2022532020A (ja) 2022-07-13
US20210385687A1 (en) 2021-12-09

Similar Documents

Publication Publication Date Title
JP6005710B2 (ja) 無線通信システムの状態情報送信方法及び受信装置
EP3576329B1 (en) Communication method and device
KR20090099485A (ko) Ｐｄｃｐ 상태 보고 전송 방법
JP2005509381A (ja) ヘッダ圧縮を行う無線通信装置
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
US11956667B2 (en) Communication method and device
WO2021179827A1 (zh) 一种通信的方法及装置
US20210274384A1 (en) Wireless communication method and device
KR20210113659A (ko) 무선 통신의 방법 및 장치
TW201832504A (zh) 傳輸回饋訊息的方法、終端設備和網路設備
US11671870B2 (en) Compression processing method, decompression processing method and related devices
CN113115361B (zh) 以太网帧头压缩处理方法、装置、芯片及计算机程序
WO2021012260A1 (zh) 用于传输数据的方法、发送端设备和接收端设备
WO2018126450A1 (zh) 无线通信的方法和设备
JP2008289149A (ja) 無線通信システムにおいてデータ伝送状態をポーリングする方法及び装置
WO2021097686A1 (zh) 用于传输以太网压缩包的方法和设备
WO2017143538A1 (zh) 语音数据传输方法以及装置
WO2020062091A1 (zh) 通信方法、终端设备和网络设备
WO2014141635A1 (ja) 無線通信装置及び送信フレーム制御方法
EP3103279B1 (en) Mtc device, serving node, and various methods for implementing an uplink stack reduction feature
WO2023024792A1 (zh) 一种数据重传方法、装置及存储介质
WO2021213186A1 (zh) 数据处理方法和装置
US20230262809A1 (en) Methods and Apparatus for Logical Channel Aggregation
CN113678501B (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: 19922297

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019922297

Country of ref document: EP

Effective date: 20210729

ENP Entry into the national phase

Ref document number: 2021557688

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20217035244

Country of ref document: KR

Kind code of ref document: A