WO2020147039A1 - 以太网帧头压缩处理方法、装置、芯片及计算机程序 - Google Patents

以太网帧头压缩处理方法、装置、芯片及计算机程序 Download PDF

Info

Publication number
WO2020147039A1
WO2020147039A1 PCT/CN2019/072001 CN2019072001W WO2020147039A1 WO 2020147039 A1 WO2020147039 A1 WO 2020147039A1 CN 2019072001 W CN2019072001 W CN 2019072001W WO 2020147039 A1 WO2020147039 A1 WO 2020147039A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
header compression
ethernet frame
static
compression object
Prior art date
Application number
PCT/CN2019/072001
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 CN202110407372.6A priority Critical patent/CN113115361B/zh
Priority to EP19910588.3A priority patent/EP3860075B1/en
Priority to CN201980054339.0A priority patent/CN112585923A/zh
Priority to PCT/CN2019/072001 priority patent/WO2020147039A1/zh
Publication of WO2020147039A1 publication Critical patent/WO2020147039A1/zh
Priority to US17/232,969 priority patent/US11736977B2/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/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Definitions

  • This application relates to wireless network technology, and in particular to methods, devices, chips and computer programs for compressing Ethernet frame headers.
  • PDU Protocol Data Unit
  • IPv4 Internet Protocol Version 4
  • IPv6 Internet Protocol Version 6
  • Ethernet frame Ethernet frame
  • Header compression refers to the compression of data packet headers to improve the transmission efficiency of user data.
  • the Packet Data Convergence Protocol (PDCP, Packet Data Convergence Protocol) uses robust header compression (RoHC, Robust Header Compression) to compress the data packet header.
  • RoHC Robust Header Compression
  • the air interface resources are limited.
  • the byte size of the packet header of the Ethernet frame is much larger than the byte size of the data part, and some sub-headers in the packet header are actually transmitted redundantly.
  • a large amount of resources are used in the transmission redundant packet header, thereby wasting air interface resources and reducing data transmission efficiency.
  • the header compression can just solve this problem, but there is no corresponding solution for how to realize the header compression of the Ethernet frame.
  • the embodiments of the present application provide methods, devices, chips, and computer programs for compressing Ethernet frame headers.
  • an Ethernet frame header compression processing method including:
  • the first device determines according to the configuration information that it is necessary to perform header compression processing on the Ethernet frame
  • the first device determines the header compression object in the Ethernet frame according to specific information
  • the first device performs header compression processing on the header compression object.
  • an Ethernet frame header compression processing device is provided, which is used to execute the method in the first aspect or its implementation manners.
  • the Ethernet frame header compression processing device includes a functional module for executing the method in the above-mentioned first aspect or each of its implementation manners.
  • a communication 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 first aspect or its implementations In the method.
  • a chip for implementing the method in the above first aspect or 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 the method as described in the first aspect or various implementations thereof.
  • a computer-readable storage medium for storing a computer program that causes a computer to execute the method in the first aspect or its various implementations.
  • a computer program product including computer program instructions, which cause the computer to execute the method in the first aspect or its various implementations.
  • a computer program which when run on a computer, causes the computer to execute the method in the first aspect or its various implementations.
  • FIG. 1 is a schematic diagram of a communication system architecture provided by an embodiment of the application.
  • FIG. 2 is a schematic diagram of the four Ethernet frame formats Ethernet II, Ethernet 802.3 raw, Ethernet 802.3 SAP, and Ethernet 802.3 SNAP provided by an embodiment of the application.
  • FIG. 3 is a schematic diagram of the VLAN frame format in the IEEE 802.1Q standard provided by an embodiment of the application.
  • FIG. 4 is a schematic flowchart of a method for compressing an Ethernet frame header according to an embodiment of the application.
  • FIG. 5 is a schematic diagram of state transition provided by an embodiment of the application.
  • FIG. 6 is a schematic structural diagram of an Ethernet frame header compression processing apparatus provided by an embodiment of the application.
  • FIG. 7 is a schematic structural diagram of a communication device 600 provided by an embodiment of the application.
  • FIG. 8 is a schematic structural diagram of a chip 700 provided by an embodiment of the application.
  • FIG. 9 is a schematic block diagram of a communication system 800 provided by an embodiment of this application.
  • GSM Global System of Mobile communication
  • CDMA Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • GSM Global System of Mobile communication
  • CDMA Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • 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
  • WiMAX Worldwide Interoperability for Microwave Access
  • FIG. 1 is a schematic diagram of a communication system architecture provided by an embodiment of this application.
  • 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 referred to as a communication terminal, terminal).
  • the network device 110 can provide communication coverage for a specific geographic area, and can communicate with terminal devices located within the coverage area.
  • the network device 110 may be a base station (BTS, Base Transceiver Station) in a GSM system or a CDMA system, a base station (NB, NodeB) in a WCDMA system, or an evolved base station in an LTE system (eNB or eNodeB, Evolutional Node B), or the wireless controller in the Cloud Radio Access Network (CRAN, Cloud Radio Access Network), or the network equipment may be a mobile switching center, a relay station, an access point, a vehicle-mounted device, 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, Public Land Mobile Network), etc.
  • BTS Base Transceiver Station
  • NB NodeB
  • eNB or eNodeB Evolutional Node B
  • CRAN Cloud Radio Access Network
  • the network equipment may be a mobile switching center, a relay station, an access point, a vehicle-mounted device, Wearable devices, hubs, switches, bridge
  • the communication system 100 also includes at least one terminal device 120 within the coverage of the network device 110.
  • the "terminal equipment” used here includes but is not limited to connection via wired lines, such as public switched telephone networks (PSTN, Public Switched Telephone Networks), digital subscriber lines (DSL, Digital Subscriber Line), 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, Wireless Local Area Network), 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.
  • PSTN public switched telephone networks
  • DSL Digital Subscriber Line
  • a terminal device set to communicate through a wireless interface may be referred to as a "wireless communication terminal", “wireless terminal”, or “mobile terminal”.
  • mobile terminals include, but are not limited to, satellites or cellular phones; Personal Communications System (PCS) terminals that can combine cellular radio phones with data processing, fax, and data communication capabilities; can include radio phones, pagers, Internet/intranet PDA with internet access, web browser, memo pad, calendar, and/or Global Positioning System (GPS) receiver; and conventional laptop and/or palmtop receivers or others including radio telephone transceivers Electronic device.
  • PCS Personal Communications System
  • GPS Global Positioning System
  • Terminal equipment can refer to access terminal, user equipment (UE, User Equipment), user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile equipment, user terminal, terminal, wireless communication equipment, user agent or User device.
  • the access terminal can be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL, Wireless Local Loop) station, a personal digital processing (PDA, Personal Digital Assistant), with wireless communication Functional handheld devices, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks, or terminal devices in the future evolution of PLMN, etc.
  • SIP Session Initiation Protocol
  • WLL Wireless Local Loop
  • PDA Personal Digital Assistant
  • terminal direct connection (D2D, Device to Device) communication may be performed between the terminal devices 120.
  • D2D Device to Device
  • the 5G system or 5G network may also be referred to as NR system or NR network.
  • the technical solution of the embodiment of the present application may be applied to the unlicensed spectrum or the authorized spectrum, which is not limited in the embodiment of the present application.
  • FIG. 1 exemplarily shows one network device and two terminal devices.
  • the communication system 100 may include multiple network devices and each network device may include other numbers of terminal devices within the coverage area. This application The embodiment does not limit this.
  • the communication system 100 may further include other network entities such as a network controller, a mobility management entity, etc. This embodiment of the present application does not limit this.
  • the devices with communication functions in the network/system in the embodiments of the present application may be referred to as communication devices.
  • the communication device may include a network device 110 having a communication function and a terminal device 120.
  • the network device 110 and the terminal device 120 may be the specific devices described above, which will not be repeated here.
  • the communication device may also include other devices in the communication system 100, such as network controllers, mobility management entities and other network entities, which are not limited in this embodiment of the application.
  • Ethernet frames There are many different formats of Ethernet frames.
  • the common and used Ethernet frame formats include but are not limited to the following: Ethernet II, Ethernet 802.3 raw, Ethernet 802.3 SAP, and Ethernet 802.3 SNAP.
  • Figure 2 is provided for this application example. Schematic diagram of four Ethernet frame formats, Ethernet II, Ethernet 802.3 raw, Ethernet 802.3 SAP, and Ethernet 802.3 SNAP.
  • each sub-header in different Ethernet frame formats. It should be noted that at the beginning of the Ethernet frame header (before the target address), there is usually a preamble field or a preamble and frame start delimiter (SFD, Start of Frame Delimiter), occupying 8 bytes .
  • SFD Start of Frame Delimiter
  • FIG. 3 is a schematic diagram of a virtual local area network (VLAN, Virtual Local Area Network) frame format in the IEEE 802.1Q standard provided by an embodiment of the application, and the sub-headers in the VLAN format are described as follows.
  • VLAN Virtual Local Area Network
  • Ethernet frames of different formats have common parts, such as destination address, source address, and type/length fields.
  • Ethernet frames of different formats also have specific parts, such as The DSAP and SSAP parts in the SAP format, the SNAP-ID, DSAP, and SSAP parts in the SNAP format.
  • each Ethernet frame can contain a VLAN subheader.
  • preamble, SFD, and FCS in the Ethernet frame are not transmitted in the 5G system.
  • preamble, SFD and FCS may not be header compressed.
  • the different types may include at least one of the following: static type, static-def type, static-known type, changing type and inferred type, etc.
  • Static type, static-def type, and static-known type can be collectively referred to as static type
  • inferred type, static type, static-def type and static-known type can be collectively referred to as the first type.
  • the different types can be as follows.
  • the static-def type can include:
  • the DSAP and/or SSAP part of the SAP format
  • the DSAP and/or SSAP part of the SNAP format.
  • Static types can include:
  • TP-ID for example, TP-ID, VID and/or CFI/DEI part.
  • the static-known types can include:
  • the changing types can include:
  • the type part in the Ethernet II format For example, the type part in the Ethernet II format
  • the length part in the SAP format For example, the length part in the SAP format
  • the length part and/or type part in the SNAP format For example, the length part and/or type part in the SNAP format
  • the PRI part in the VLAN subheader For example, the PRI part in the VLAN subheader
  • Inferred types can include:
  • the org code part in the SNAP format For example, the org code part in the SNAP format.
  • the DASP and/or SSAP part of the SNAP format can be classified as static-known.
  • the Cntl part of the SAP format can be classified as static-def type or static-known type.
  • the Cntl part of the SNAP format can be classified as static-def type, inferred type, or changing type.
  • the length part in the SAP format can be classified as an inferred type, and the length part in the SNAP format can also be classified as an inferred type.
  • the type part in the Ethernet II format can be classified as inferred type or static type.
  • the org code part of the SNAP format can be classified as static-known or static.
  • the TP-ID and/or CFI/DEI part in the VLAN subheader can be classified as an inferred type or a changing type.
  • the destination address, source address, DSAP and/or SSAP can be classified as static types.
  • the Cntl part of the SAP format can also be classified as a changing type.
  • the EtherType part can also be classified as an inferred type, and the EtherType part can include: the EtherType part in the Ethernet II format, the EtherType part in the SAP format, and/or the EtherType part in the SNAP format.
  • Ethernet frames are carried in PDU session or Quality of Service flow (QoS flow, Quality of Service flow) or Radio Bearer (DRB, Data Radio Bearer)
  • QoS flow Quality of Service flow
  • DRB Radio Bearer
  • the header of the Ethernet frame can be based on PDU session or QoS flow or DRB. compression.
  • the header compression object can include at least one of the following:
  • the first type of header compression object can include: common in different Ethernet frame formats and belong to the static type (including at least one of the following types: static type, static-def type, static-known type) For example, the destination address and source address.
  • the second type of header compression object may include: common parts in different Ethernet frame formats, such as destination address, source address, and EtherType parts.
  • the third type of header compression object can include: the first type of header compression object, and each unique static type in different Ethernet frame formats (including at least one of the following types: static type, static-def type, static-known type).
  • the fourth type of header compression object, the fourth type of header compression object may include: the second type of header compression object, and each unique static type in different Ethernet frame formats (including at least one of the following types: static type, static-def type, static-known type).
  • the fifth type of header compression object can include: all the parts of different types in the Ethernet frame, that is, the different types of parts in the Ethernet frame are regarded as header compression objects. Generally speaking, the types are different , The compression method will be different.
  • the sixth type of header compression object may include: parts that are common in different Ethernet frame formats and belong to the first type.
  • the first type may include at least one of the following types: inferred type, static type, Static-def type, static-known type.
  • the seventh type of header compression object may include: the sixth type of header compression object, and the unique part of the first type in different Ethernet frame formats.
  • the eighth type of header compression object, the eighth type of header compression object may include: the second type of header compression object, and the respective unique parts of the first type in different Ethernet frame formats.
  • the foregoing various header compression objects may also include at least one of the following:
  • the part of the VLAN subheader that belongs to the static type (including at least one of the following types: static type, static-def type, static-known type);
  • the part of the VLAN subheader that belongs to the first type (including at least one of the following types: inferred type, static type, static-def type, static-known type);
  • header compression objects have their own advantages. For example, for the first type of header compression objects, there is no need to distinguish between different frame formats, which is the simplest method of header compression processing; the second type of header compression objects are in the first type. On the basis of the header compression object, the processing of non-static common parts in each Ethernet frame format is added, thereby improving the compression efficiency; the third and fourth types of header compression objects are in the first and second types of header compression objects On the basis of, the unique static type part of each Ethernet frame format is added to further improve the compression efficiency; the fifth type of header compression object has the highest compression efficiency, but the compression end and the decompression end need to distinguish between different Ethernet frame formats At the same time, the compression problem of the variable type part should be considered.
  • the compression processing scheme is more complicated.
  • the Ethernet frame contains the VLAN subheader, it can also solve the problem of how the VLAN subheader handles the header compression in the Ethernet frame.
  • the padding part is not transmitted in the compressed Ethernet frame to improve the transmission efficiency, and subsequently, the padding part is automatically filled during decompression.
  • FIG. 4 is a schematic flowchart of a method for compressing an Ethernet frame header according to an embodiment of the application. As shown in Figure 4, the following specific implementations are included.
  • the first device determines according to the configuration information that it is necessary to perform header compression processing on the Ethernet frame.
  • the first device determines the header compression object in the Ethernet frame according to the specific information.
  • the first device performs header compression processing on the header compression object.
  • the first device may be a terminal device or a network device, and the network device may be a base station or a core network device. If the first device is a terminal device, the terminal device will be the compression terminal and the network device will be the decompression terminal. If the first device is a network device, the network device will be the compression terminal and the terminal device will be the decompression terminal.
  • the following uses the first device as a terminal device as an example to describe the solution described in this embodiment.
  • the configuration information may include first dedicated information.
  • the network device can use the first dedicated information to configure whether the terminal device performs header compression processing on the Ethernet frame information header.
  • the first dedicated information is profile.
  • the configuration information may also include second dedicated information.
  • the network device uses the second dedicated information to configure each type of context information of the terminal device in the header compression process.
  • the second dedicated information is the maximum number of contexts MAX_CID.
  • the terminal device can determine whether header compression processing is required for the Ethernet frame according to the dedicated information used by the Ethernet frame information header, such as the configured profile information. If the result of the determination is yes, the header compression object needs to be determined according to specific information, and then header compression processing can be performed on the header compression object.
  • the method of determining the header compression object according to the specific information may include: determining the header compression object according to predefined information, or determining the header compression object according to instruction information, or determining the header compression object according to first specific information such as profile information.
  • the first dedicated information is the profile information used in the Ethernet frame information header as an example, and the solution described in this embodiment is described in detail through specific examples.
  • the terminal device can determine whether it needs to perform header compression processing on the Ethernet frame according to the profile information configured by the network device. For example, a network device can configure the profile used by the Ethernet frame information header through a radio resource control (RRC, Radio Resource Control) message, that is, introduce a new profile, such as adding a new IE to PDCP-config:
  • RRC Radio Resource Control
  • profile0x0105 is the newly added IE.
  • the terminal device can determine whether header compression processing is required for the Ethernet frame according to the value of the acquired profile. For example, if the value of profile0x0105 is true, it determines that header compression processing is required for the Ethernet frame.
  • the terminal device can determine the head compression object according to the predefined information.
  • the predefined information may be pre-written in the protocol, or it may be indicated by the network device when the terminal device initially accesses it, or it may be notified in the broadcast.
  • the static type part of the Ethernet frame is used as the header compression object.
  • it may be written in the protocol to perform header compression processing on the static type common parts of each Ethernet frame format.
  • the protocol can specify which sub-fields in the Ethernet frame format or each Ethernet frame format are subject to header compression processing.
  • determining which subdomains to perform header compression processing can be determined according to the type of subdomain.
  • the terminal device After the terminal device determines the first compression target, it can adopt the corresponding compression mode, such as unidirectional U mode (uni-directional mode) or bi-directional reliable R mode (R mode, bi-directional reliable mode) or bidirectional optimized O mode ( O mode, bi-directional optimistic mode), performs header compression processing, and correspondingly migrates in accordance with the transmission conditions in the three header compression states.
  • the terminal device can also submit the compressed data packet obtained by compression to the PDCP layer and/or radio link control (RLC, Radio Link Control) layer processing.
  • RLC Radio Link Control
  • the network device acts as a decompression terminal, decompresses the compressed data packet, and submits the decompressed packet upward. Specifically, after receiving the compressed data packet from the terminal device, the network device can map the compressed data packet to a different context ID queue according to the profile and the context identifier (CID, Context ID) (carried in the compressed data packet), and use U mode or R mode or O mode performs decompression processing, and correspondingly migrates according to transmission conditions in the three decompression states, and subsequently, the network device may also send a header compression feedback packet to the terminal device.
  • CID context identifier
  • the compression end and the decompression end have three states respectively, namely the initialization state, the intermediate state and the complete state, which represent the different efficiency of header compression (from low to high).
  • the initialization and update state IR, Initialization and Refresh
  • the intermediate state FO, First Order
  • SO, Second Order the highest state
  • the decompression end it is called the no Context state (NC, No Context), static context state (SC, Static Context), and full context state (FC, Full Context).
  • NC No Context
  • SC static context state
  • FC Full Context
  • the compression end and the decompression end migrate between these states according to certain rules to complete the header compression and decompression operations.
  • IR packet initialization packet, including static chain header, optional variable chain header
  • IR-DYN packet including variable chain header
  • packet type packet type 1
  • packet type 2 packet type 2
  • the IR-DYN packet or packet type 2 is transmitted between the compression end and the decompression end.
  • the highest compression and decompression state or the context information is correct the highest state
  • all types of packets are transmitted between the compression end and the decompression end.
  • the format of the compressed Ethernet frame header can be as follows (take Ethernet/RTP/UDP/IP as an example):
  • the compressed Ethernet frame header format can be as follows (take Ethernet/RTP/UDP/IP as an example):
  • the format of the compressed Ethernet frame header can be as follows (without IP packet as an example):
  • the expansion scheme of the VLAN domain can also be:
  • the compression end and the decompression end only migrate between two states: the initial state and the complete state.
  • migration is performed between the initialization and update state IR and the highest state SO, and for the decompression end, migration is performed between the no-context state NC and the full-context state FC.
  • the IR packet can be used for initialization, and the profile corresponding to the Ethernet frame is used.
  • the static chain ends with the static part of the Ethernet frame.
  • the profile information can be configured or indicated based on the PDU session or QoS flow or DRB.
  • the header compression object of the PDU session or QoS flow carried on each bearer may be the same or different. The advantage is that it increases the flexibility of header compression and supports different header compression processing according to different data streams.
  • the terminal device can determine whether it needs to perform header compression processing on the Ethernet frame according to the profile information configured by the network device.
  • the terminal device may also determine the header compression object according to the indication information of the network device, for example, the header compression object may be determined according to the indication of the dedicated signaling indication information.
  • the dedicated signaling may be RRC signaling, Media Access Control Control Element (MAC CE, Media Access Control Control Element), or downlink control information (DCI, Downlink Control Information), etc.
  • the dedicated signaling can be issued together with other header compression configurations, or it can be a new configuration/instruction information.
  • the dedicated signaling can be configured or indicated based on the PDU session or QoS flow or DRB.
  • the header compression object of the PDU session or QoS flow carried on each bearer may be the same or different. The advantage is that it increases the flexibility of header compression and supports different header compression processing according to different data streams.
  • profile0x0105 and ObjectEthernet are newly added IEs.
  • the terminal device can determine whether to perform header compression processing on the Ethernet frame according to the value of the acquired profile. For example, if the value of profile0x0105 is true, it can determine that header compression processing is required on the Ethernet frame.
  • the terminal device can determine the header compression object according to the value of ObjectEthernet.
  • the value is "static" it means that the static part of the Ethernet frame is used as the header compression object
  • the value is "all”
  • the value format of ObjectEthernet is not limited to "static” and “all”, but can also be in other forms, such as option1, option2, option3, etc.
  • Different options represent different header compression objects.
  • option1 represents the first A type of header compression object, that is, the part that is common to all Ethernet frame formats and belongs to the static type.
  • the terminal device determines the header compression object, how to perform subsequent header compression processing and how the network device performs decompression, etc. can refer to the relevant description in Example 1, and will not be repeated.
  • the compression strength and efficiency can be modified according to the instructions of the network device, which increases the flexibility of the header compression processing.
  • the network device can configure multiple profile information used by the Ethernet frame information header through the RRC message, and different profile information can represent different header compression objects. At the same time, the terminal device can determine whether it needs to perform header compression processing on the Ethernet frame according to the profile information.
  • the profile information can be configured or indicated based on the PDU session or QoS flow or DRB.
  • the header compression object of the PDU session or QoS flow carried on each bearer may be the same or different. The advantage is that it increases the flexibility of header compression and supports different header compression processing according to different data streams.
  • profile0x0105, profile0x0106, profile0x0107, profile0x0108, profile0x0115, profile0x0116, profile0x0117, and profile0x0118 are newly added IEs, and the header compression objects they represent can be shown in the following table.
  • the corresponding header compression object can be determined to be "Ethernet static class".
  • the static type part of the Ethernet frame is used as the header compression object, and the RFC protocol referred to is RFC3095, etc.
  • the header compression object represented by "Ethernet/VLAN static class” is the static type part of the Ethernet frame and the VLAN subheader The part belongs to the static type.
  • the header compression object represented by "Ethernet” is all the parts of different types in the Ethernet frame.
  • header compression objects shown in the above table are only examples and are not used to limit the technical solutions of this application. In actual applications, there can be more granular profile definitions according to actual needs, indicating different The header compression object or header compression granularity, etc.
  • the terminal device determines the header compression object, how to perform subsequent header compression processing and how the network device performs decompression, etc. can refer to the relevant description in Example 1, and will not be repeated.
  • the above description takes the terminal device as the compression end and the network device as the decompression end as an example. If the network device is the compression end and the terminal device is the decompression end, the processing method is similar.
  • the network device can be configured according to the configuration or the configuration from the core network. Determine whether it is necessary to perform header compression processing on the Ethernet frame and determine the header compression object, and then perform header compression processing on the determined header compression object, and transmit the obtained compressed data packet to the terminal device for decompression, etc.
  • the network device can be configured according to the configuration or the configuration from the core network. Determine whether it is necessary to perform header compression processing on the Ethernet frame and determine the header compression object, and then perform header compression processing on the determined header compression object, and transmit the obtained compressed data packet to the terminal device for decompression, etc.
  • the aforementioned related descriptions which will not be repeated here.
  • header compression of the Ethernet frame can be realized, thereby saving air interface resources and improving data transmission efficiency.
  • FIG. 6 is a schematic structural diagram of an Ethernet frame header compression processing apparatus provided by an embodiment of the application. As shown in FIG. 6, it includes: a determining unit 601 and a compression unit 602.
  • the determining unit 601 is configured to determine, according to the configuration information, that the Ethernet frame needs to be subjected to header compression processing, and determine the header compression object in the Ethernet frame according to specific information.
  • the compression unit 602 is configured to perform header compression processing on the header compression object.
  • the determining unit 601 may determine, according to the first dedicated information, that it is necessary to perform header compression processing on the Ethernet frame, and may also determine the header compression object according to the specific information, and then may perform header compression processing on the header compression object.
  • the method of determining the header compression object according to the specific information may include: determining the header compression object according to predefined information, or determining the header compression object according to instruction information, or determining the header compression object according to the first specific information.
  • the first dedicated information may include: profile information used by the Ethernet frame information header.
  • the determined header compression object may include at least one of the following:
  • the first type of header compression object includes: the parts that are common in different Ethernet frame formats and belong to the static type;
  • the second type of header compression object includes: common parts in different Ethernet frame formats;
  • the third type of header compression object includes: the first type of header compression object, and the static type parts unique to each of different Ethernet frame formats;
  • the fourth type of header compression object includes: the second type of header compression object, and the static type parts unique to each of different Ethernet frame formats;
  • the fifth type of header compression object includes: all parts of different types in the Ethernet frame;
  • the sixth type of header compression object includes: common parts of different Ethernet frame formats and belonging to the first type;
  • the seventh type of header compression object includes: the sixth type of header compression object, and the unique part of the first type in different Ethernet frame formats;
  • the eighth type of header compression object includes: the second type of header compression object, and the unique part of the first type in different Ethernet frame formats.
  • the foregoing various header compression objects may also include at least one of the following:
  • the padding part is not transmitted in the compressed Ethernet frame to improve the transmission efficiency, and subsequently, the padding part is automatically filled in during decompression, and/or the padding part in the Ethernet frame
  • the preamble, SFD, and FCS are not transmitted in the 5G system, and the preamble, SFD, and/or FCS in the Ethernet frame may not be header compressed.
  • Ethernet frames of different formats have common parts, and at the same time, Ethernet frames of different formats also have their specific parts. According to the transmission characteristics of the sub-headers in different Ethernet frame formats, different sub-headers can be classified into different types.
  • the different types may include at least one of the following: static type, static-def type, static-known type, changing type, inferred type, etc.
  • static type, static-def type and static-known type can be collectively referred to as static type
  • inferred type, static type, static-def type and static-known type can be collectively referred to as the first type.
  • the part that belongs to the static type usually includes at least one of the following types: static type, static-def type, static-known type.
  • the part belonging to the first type usually includes at least one of the following types: inferred type, static type, static-def type, static-known type.
  • the device shown in FIG. 6 can be applied to terminal equipment as well as network equipment.
  • profile information configured by the network device and/or indication information of the network device can be obtained.
  • FIG. 7 is a schematic structural diagram of a communication device 600 provided by an embodiment of the application.
  • the communication device 600 shown in FIG. 7 includes a processor 610, and the processor 610 can call and run a computer program from the memory 620 to implement the method in the embodiment of the present application.
  • the communication device 600 may further include a memory 620.
  • the processor 610 can call and run a computer program from the memory 620 to implement the method in the embodiments of the present application.
  • the memory 620 may be a separate device unique to the processor 610, or may be integrated in the processor 610.
  • the communication device 600 may further include a transceiver 630, and the processor 610 may control the transceiver 630 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 630 may include a transmitter and a receiver.
  • the transceiver 630 may further include antennas, and the number of antennas may be one or more.
  • the communication device 600 may specifically be a network device according to an embodiment of the present application, and the communication device 600 may implement the corresponding process implemented by the network device in each method of the embodiment of the present application. .
  • the communication device 600 may specifically be a mobile terminal/terminal device according to an embodiment of the present application, and the communication device 600 may implement the corresponding process implemented by the mobile terminal/terminal device in each method of the embodiment of the present application, for simplicity And will not be repeated here.
  • FIG. 8 is a schematic structural diagram of a chip 700 provided by an embodiment of the application.
  • the chip 700 shown in FIG. 8 includes a processor 710, and the processor 710 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the chip 700 may further include a memory 720.
  • the processor 710 can call and run a computer program from the memory 720 to implement the method in the embodiments of the present application.
  • the memory 720 may be a separate device unique to the processor 710, or it may be integrated in the processor 710.
  • the chip 700 may further include an input interface 730.
  • the processor 710 can control the input interface 730 to communicate with other devices or chips. Specifically, it can obtain information or data sent by other devices or chips.
  • the chip 700 may further include an output interface 740.
  • the processor 710 can control the output interface 740 to communicate with other devices or chips. Specifically, it can output information or data to other devices or chips.
  • the chip can be applied to the network 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 can be applied to the mobile terminal/terminal device in the embodiments of the present application, and the chip can implement the corresponding process implemented by the mobile terminal/terminal device in each method of the embodiments of the present application. No longer.
  • chips mentioned in the embodiments of the present application may also be referred to as system-level chips, system chips, chip systems, or system-on-chip chips.
  • FIG. 9 is a schematic block diagram of a communication system 800 provided by an embodiment of this application. As shown in FIG. 9, the communication system 800 includes a terminal device 810 and a network device 820.
  • the terminal device 810 can be used to implement the corresponding function implemented by the terminal device in the above method
  • the network device 820 can be used to implement the corresponding function implemented by the network device in the above method. For the sake of brevity, it will not be omitted here. Repeat.
  • 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 may be completed by instructions in the form of hardware integrated logic circuits or software in the processor.
  • the above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), an application specific integrated circuit (ASIC, Application Specific Integrated Circuit), a ready-made programmable gate array (FPGA, Field Programmable Gate Array), or other Programming logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • DSP digital signal processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • Programming logic devices discrete gates or transistor logic devices, discrete hardware components.
  • the general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed and completed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module may be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, and a register.
  • 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 embodiments of the present application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (ROM, Read-Only Memory), programmable read-only memory (PROM, Programmable ROM), erasable programmable read-only memory (EPROM, Erasable PROM), and Erase programmable read-only memory (EEPROM, Electrically EPROM) or flash memory.
  • the volatile memory may be a random access memory (RAM, Random Access Memory), which is used as an external cache.
  • RAM By way of exemplary but not restrictive description, many forms of RAM are available, such as static random access memory (SRAM, Static RAM), dynamic random access memory (DRAM, Dynamic RAM), synchronous dynamic random access memory (SDRAM, Synchronous DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, Double Data Rate SDRAM), enhanced synchronous dynamic random access memory (ESDRAM, Enhanced SDRAM), synchronous connection dynamic random access memory (SLDRAM, Synchrolink DRAM) ) And Direct Rambus RAM (DR RAM, Direct Rambus RAM).
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • Dynamic RAM synchronous dynamic random access memory
  • SDRAM Synchronous DRAM
  • DDR SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM Synchrolink DRAM
  • Direct Rambus RAM Direct Rambus RAM
  • Embodiments of the present application also provide a computer-readable storage medium for storing computer programs.
  • the computer-readable storage medium may be applied to the network device in the embodiments 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 embodiments 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 embodiments of the present application.
  • the computer-readable storage medium may be applied to the mobile terminal/terminal device in the embodiments 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 embodiments of the present application For the sake of brevity, I will not repeat them here.
  • An embodiment of the present application also provides a computer program product, including computer program instructions.
  • the computer program product may be applied to the network device in the embodiments 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. Repeat again.
  • the computer program product can be applied to the mobile terminal/terminal device in the embodiments 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 embodiments of the present application, For brevity, I will not repeat them here.
  • the embodiment of the 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 allowed to execute the corresponding process implemented by the network device in each method of the embodiment of the present application. And will not be repeated 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 purpose of the solution of this embodiment.
  • each functional 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 a unique product, it can be stored in a computer readable storage medium.
  • the technical solution of the present application essentially or part of the contribution to the existing technology or part of the technical solution can be embodied in the form of a software product
  • the computer software product is stored in a storage medium, including Several instructions are used to enable a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application.
  • the foregoing storage media include various media that can store program codes, such as a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

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

Abstract

本申请公开了以太网帧头压缩处理方法、装置、芯片及计算机程序，其中方法包括：第一设备根据配置信息确定需要对以太网帧进行头压缩处理，根据特定信息确定出头压缩对象；第一设备对头压缩对象进行头压缩处理。应用本申请所述方案，可实现以太网帧的头压缩，从而节省了空口资源，提升了数据传输效率等。

Description

以太网帧头压缩处理方法、装置、芯片及计算机程序 技术领域
本申请涉及无线网络技术，特别涉及以太网帧头压缩处理方法、装置、芯片及计算机程序。
背景技术
传统的通信系统中，仅支持对协议数据单元(PDU，Protocol Data Unit)会话(session)的类型为IP包的数据包进行头压缩(header compression)。而在5G新无线(NR，New Radio)系统中，PDU会话的类型不仅可以为IP包类型，如互联网协议版本4(IPv4)和互联网协议版本6(IPv6)等，还可以为以太网帧(Ethernet frame)类型。
头压缩即指对数据包包头进行压缩，用于提高用户数据的传输效率。分组数据汇聚协议(PDCP，Packet Data Convergence Protocol)中采用健壮性包头压缩(RoHC，Robust Header Compression)对数据包包头进行头压缩。
对于以太网帧，空口资源有限，在一定场景下，以太网帧的包头需要的字节大小远大于数据部分的字节大小，而且包头中的部分子头实际上是冗余传输的，这样就造成了大量的资源使用在传输冗余的包头上，从而浪费了空口资源，降低了数据传输效率。而头压缩正好可以解决这一问题，但对于如何实现以太网帧的头压缩，目前还没有相应的解决方式。
发明内容
有鉴于此，本申请实施例提供了以太网帧头压缩处理方法、装置、芯片及计算机程序。
第一方面，提供了一种以太网帧头压缩处理方法，包括：
第一设备根据配置信息确定需要对以太网帧进行头压缩处理；
所述第一设备根据特定信息确定出以太网帧中的头压缩对象；
所述第一设备对所述头压缩对象进行头压缩处理。
第二方面，提供了一种以太网帧头压缩处理装置，用于执行上述第一方面或其各实现方式中的方法。
具体地，该以太网帧头压缩处理装置包括用于执行上述第一方面或其各实现方式中的方法的功能模块。
第三方面，提供了一种通信设备，包括处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第一方面或其各实现方式中的方法。
第四方面，提供了一种芯片，用于实现上述第一方面或其各实现方式中的方法。
具体地，该芯片包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有该芯片的设备执行如上述第一方面或其各实现方式中的方法。
第五方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述第一方面或其各实现方式中的方法。
第六方面，提供了一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述第一方面或其各实现方式中的方法。
第七方面，提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面或其各实现方式中的方法。
基于上述介绍可以看出，采用本申请所述方案，可实现以太网帧的头压缩，从而节省了空口资源，提升了数据传输效率。
附图说明
图1为本申请实施例提供的一种通信系统架构的示意性图。
图2为本申请实施例提供的Ethernet II、Ethernet 802.3 raw、Ethernet 802.3 SAP以及Ethernet 802.3 SNAP四种以太网帧格式的示意图。
图3为本申请实施例提供的IEEE 802.1Q标准中的VLAN帧格式示意图。
图4为本申请实施例提供的以太网帧头压缩处理方法的示意性流程图。
图5为本申请实施例提供的状态迁移示意图。
图6为本申请实施例提供的以太网帧头压缩处理装置的示意性结构图。
图7为本申请实施例提供的通信设备600的示意性结构图。
图8为本申请实施例提供的芯片700的示意性结构图。
图9为本申请实施例提供的通信系统800的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。本实施例适用于以太网帧中不携带IP包的帧结构，也可以适用于以太网帧中携带IP包的帧结构。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例的技术方案可以应用于各种通信系统，比如：全球移动通讯(GSM，Global System of Mobile communication)系统、码分多址(CDMA，Code Division Multiple Access)系统、宽带码分多址(WCDMA，Wideband Code Division Multiple Access)系统、通用分组无线业务(GPRS，General Packet Radio Service)、长期演进(LTE，Long Term Evolution)系统、LTE频分双工(FDD，Frequency Division Duplex)系统、LTE时分双工(TDD，Time Division Duplex)、通用移动通信系统(UMTS，Universal Mobile Telecommunication System)、全球互联微波接入(WiMAX，Worldwide Interoperability for Microwave Access)通信系统或5G系统等。
示例性的，图1为本申请实施例提供的一种通信系统架构的示意性图。该通信系统100可以包括网络设备110，网络设备110可以是与终端设备120(或称为通信终端、终端)通信的设备。网络设备110可以为特定的地理区域提供通信覆盖，并且可以与位于该覆盖区域内的终端设备进行通信。可选地，该网络设备110可以是GSM系统或CDMA系统中的基站(BTS，Base Transceiver Station)，也可以是WCDMA系统中的基站(NB，NodeB)，还可以是LTE系统中的演进型基站(eNB或eNodeB，Evolutional Node B)，或者是云无线接入网络(CRAN，Cloud Radio Access Network)中的无线控制器，或者该网络设备可以为移动交换中心、中继站、接入点、车载设备、可穿戴设备、集线器、交换机、网桥、路由器、5G网络中的网络侧设备或者未来演进的公共陆地移动网络(PLMN，Public Land Mobile Network)中的网络设备等。
该通信系统100还包括位于网络设备110覆盖范围内的至少一个终端设备120。作为在此使用的“终端设备”包括但不限于经由有线线路连接，如经由公共交换电话网络(PSTN，Public Switched Telephone Networks)、数字用户线路(DSL，Digital Subscriber Line)、数字电缆、直接电缆连接；和/或另一数据连接/网络；和/或经由无线接口，如，针对蜂窝网络、无线局域网(WLAN，Wireless Local Area Network)、诸如DVB-H网络的数字电视网络、卫星网络、AM-FM广播发送器；和/或另一终端设备的被设置成接收/发送通信信号的装置；和/或物联网(IoT，Internet of Things)设备。被设置成通过无线接口通信的终端设备可以被称为“无线通信终端”、“无线终端”或“移动终端”。移动终端的示例包括但不限于卫星或蜂窝电话；可以组合蜂窝无线电电话与数据处理、传真以及数据通信能力的个人通信系统(PCS，Personal Communications System)终端；可以包括无线电电话、寻呼机、因特网/内联网接入、Web浏览器、记事簿、日历以及/或全球定位系统(GPS，Global Positioning System)接收器的PDA；以及常规膝上型和/或掌上型接收器或包括无线电电话收发器的其它电子装置。终端设备可以指接入终端、用户设备(UE，User Equipment)、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。接入终端可以是蜂窝电话、无绳电话、会话启动协议(SIP，Session Initiation Protocol)电话、无线本地环路(WLL，Wireless Local Loop)站、个人数字处理(PDA，Personal Digital Assistant)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备、5G网络 中的终端设备或者未来演进的PLMN中的终端设备等。
可选地，终端设备120之间可以进行终端直连(D2D，Device to Device)通信。
可选地，5G系统或5G网络还可以称为NR系统或NR网络。
本申请实施例的技术方案可以应用于免授权频谱，也可以应用于授权频谱，本申请实施例对此并不限定。
图1示例性地示出了一个网络设备和两个终端设备，可选地，该通信系统100可以包括多个网络设备并且每个网络设备的覆盖范围内可以包括其它数量的终端设备，本申请实施例对此不做限定。
可选地，该通信系统100还可以包括网络控制器、移动管理实体等其他网络实体，本申请实施例对此不作限定。
应理解，本申请实施例中网络/系统中具有通信功能的设备可称为通信设备。以图1示出的通信系统100为例，通信设备可包括具有通信功能的网络设备110和终端设备120，网络设备110和终端设备120可以为上文所述的具体设备，此处不再赘述；通信设备还可包括通信系统100中的其他设备，比如网络控制器、移动管理实体等其他网络实体，本申请实施例中对此不做限定。
应理解，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，比如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
以太网帧有很多不同格式，如目前常见并使用的以太网帧格式包括但不限于以下几种：Ethernet II、Ethernet 802.3 raw、Ethernet 802.3 SAP以及Ethernet 802.3 SNAP，图2为本申请实施例提供的Ethernet II、Ethernet 802.3 raw、Ethernet 802.3 SAP以及Ethernet 802.3 SNAP四种以太网帧格式的示意图。
以下分别对不同以太网帧格式中的每个子头进行说明。需要说明的是，在以太网帧头部开始位置(目标地址之前)，通常还会存在前导字符(preamble)域或preamble与帧开始定界符(SFD，Start of Frame Delimiter)，占用8字节。
Figure PCTCN2019072001-appb-000001
表1 Ethernet II格式
Figure PCTCN2019072001-appb-000002
Figure PCTCN2019072001-appb-000003
表2 Ethernet 802.3raw格式
Figure PCTCN2019072001-appb-000004
表3 Ethernet 802.3SAP格式
Figure PCTCN2019072001-appb-000005
表4 Ethernet 802.3SNAP格式
在IEEE 802.1Q标准中，对以太网帧格式进行了修改，在源地址域和类型域之间加入了4字节的802.1Q标签(802.1Q Tag)，形成了802.1Q标签，如图3所示，图3为本申请实施例提供的IEEE 802.1Q标准中的虚拟局域网(VLAN，Virtual Local Area Network)帧格式示意图，VLAN格式中的子头说明如下。
Figure PCTCN2019072001-appb-000006
Figure PCTCN2019072001-appb-000007
表5 VLAN格式
基于上述各表中的说明可以看出：不同格式的以太网帧存在共有的部分，如目的地址、源地址和type/length域等，同时，不同格式的以太网帧也有其特定的部分，如SAP格式中的DSAP和SSAP等部分，SNAP格式中的SNAP-ID、DSAP和SSAP等部分，另外，考虑到对VLAN的支持，每个以太网帧中均可包含VLAN子头。
以太网帧中的preamble、SFD、FCS不在5G系统内传输。相应的，可不对preamble、SFD和FCS进行头压缩。
基于上述各表中的子头说明以及子头传输特性，可以将不同子头归入不同的类型(class)。
所述不同类型可至少包括以下之一：静态(static)类型、静态定义(static-def)类型、静态获知(static-known)类型，可变(changing)类型和推断(inferred)类型等，其中，static类型、static-def类型和static-known类型可统称为静态类型，inferred类型、static类型、static-def类型和static-known类型可统称为第一类型。不同类型可分别如下所示。
static-def类型可包括：
A、各以太网帧格式中共有的部分，如目的地址和源地址；
B、各以太网帧格式中各自独有部分，独有部分中的不变化或基本不变化的部分；
比如，SAP格式中的DSAP和/或SSAP部分；
比如，SNAP格式中的DSAP和/或SSAP部分。
static类型可包括：
A、比如，SAP格式中的Cntl部分；
B、VLAN子头中的独有部分，独有部分中的不变化或基本不变化的部分；
比如，TP-ID、VID和/或CFI/DEI部分。
static-known类型可包括：
比如，SNAP格式中的Cntl部分。
changing类型可包括：
比如，Ethernet II格式中的类型(type)部分；
比如，SAP格式中的长度(length)部分；
比如，SNAP格式中的length部分和/或type部分；
比如，VLAN子头中的PRI部分；
type部分和length部分均属于EtherType部分。
inferred类型可包括：
比如，SNAP格式中的org code部分。
上述各归类方式仅为举例说明，并不用于限制本申请的技术方案，在实际应用中，可根据实际需要，灵活定义各部分所属的类型。
比如，SNAP格式中的DASP和/或SSAP部分可归类为static-known类型。
再比如，SAP格式中的Cntl部分可归类为static-def类型或static-known类型。
再比如，SNAP格式中的Cntl部分可归类为static-def类型或inferred类型或changing类型。
再比如，SAP格式中的length部分可归类为inferred类型，SNAP格式中的length部分也可归类为inferred类型。
再比如，Ethernet II格式中的type部分可归类为inferred类型或static类型。
再比如，SNAP格式中的org code部分可归类为static-known类型或static类型。
再比如，VLAN子头中的TP-ID和/或CFI/DEI部分可归类为inferred类型或changing类型。
再比如，目的地址、源地址、DSAP和/或SSAP可归类为static类型。
再比如，SAP格式中的Cntl部分也可归类为changing类型。
再比如，EtherType部分也可归类为inferred类型，EtherType部分可包括：Ethernet II格式中的EtherType部分、SAP格式中的EtherType部分和/或SNAP格式中的EtherType部分。
上述各归类方式可结合使用。
当PDU session或服务质量流(QoS flow，Quality of Service flow)或无线承载(DRB，Data Radio Bearer)中承载的是以太网帧时，可以基于PDU session或QoS flow或DRB进行以太网帧的头压缩。
头压缩对象至少可包括以下之一：
第一类头压缩对象，第一类头压缩对象中可包括：不同以太网帧格式中共有的且属于静态类型(至少包括以下类型之一：static类型、static-def类型、static-known类型)的部分，比如，目的地址和源地址部分。
第二类头压缩对象，第二类头压缩对象中可包括：不同以太网帧格式中共有的部分，比如，目的地址、源地址和EtherType部分。
第三类头压缩对象，第三类头压缩对象中可包括：第一类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型(至少包括以下类型之一：static类型、static-def类型、static-known类型)的部分。
第四类头压缩对象，第四类头压缩对象中可包括：第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型(至少包括以下类型之一：static类型、static-def类型、static-known类型)的部分。
第五类头压缩对象，第五类头压缩对象中可包括：以太网帧中所有属于不同类型的部分，即将以太网帧中的不同不同类型部分均作为头压缩对象，通常来说，类型不同，压缩方式也会不同。
第六类头压缩对象，第六类头压缩对象中可包括：不同以太网帧格式中共有的且属于第一类型的部分，第一类型可至少包括以下类型之一：inferred类型、static类型、static-def类型、static-known类型。
第七类头压缩对象，第七类头压缩对象中可包括：第六类头压缩对象，以及，不同以太网 帧格式中各自独有的属于第一类型的部分。
第八类头压缩对象，第八类头压缩对象中可包括：第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分。
另外，当以太网帧中包含VLAN子头时，上述各类头压缩对象中还可至少包括以下之一：
VLAN子头中属于静态类型(至少包括以下类型之一：static类型、static-def类型、static-known类型)的部分；
VLAN子头中属于第一类型(至少包括以下类型之一：inferred类型、static类型、static-def类型、static-known类型)的部分；
VLAN子头中所有属于不同类型的部分。
不同类的头压缩对象分别有其各自的优势，比如：对于第一类头压缩对象，不需要区分不同的帧格式，是最简单的头压缩处理方式；第二类头压缩对象在第一类头压缩对象的基础上，增加了对各以太网帧格式中非静态的共同部分的处理，从而提高了压缩效率；第三和第四类头压缩对象在第一类和第二类头压缩对象的基础上，增加了各以太网帧格式中独有的静态类型部分，从而进一步提高压缩效率；第五类头压缩对象的压缩效率最高，但压缩端和解压缩端需要区分不同的以太网帧格式，同时要考虑可变类型部分的压缩问题，压缩处理方案比较复杂；另外，当以太网帧中包含VLAN子头时，还可以解决以太网帧中存在VLAN子头如何处理头压缩的问题。
在上述基础上，还可采用以下处理方式：补充(padding)部分在压缩后的以太网帧中不传输，以提升传输效率，后续，解压缩时自动补齐padding部分。
基于上述介绍，图4为本申请实施例提供的以太网帧头压缩处理方法的示意性流程图。如图4所示，包括以下具体实现方式。
在401中，第一设备根据配置信息确定需要对以太网帧进行头压缩处理。
在402中，第一设备根据特定信息确定出以太网帧中的头压缩对象。
在403中，第一设备对头压缩对象进行头压缩处理。
在实际应用中，第一设备可以为终端设备，也可以为网络设备，而网络设备可为基站或核心网设备等。若第一设备为终端设备，那么终端设备将为压缩端，网络设备将为解压缩端，若第一设备为网络设备，那么网络设备将为压缩端，而终端设备将为解压缩端。以下以第一设备为终端设备为例，对本实施例所述方案进行说明。
具体的，所述配置信息可以包括第一专用信息。网络设备可利用第一专用信息，配置终端设备是否对以太网帧信息头进行头压缩处理。可选的，第一专用信息为profile。进一步的，所述配置信息还可以包括第二专用信息。网络设备利用第二专用信息，配置终端设备在头压缩过程中的每一种上下文信息。可选的，第二专用信息为最大context数MAX_CID。终端设备可根据以太网帧信息头使用的专用信息，如配置的profile信息确定出是否需要对以太网帧进行头压缩处理。若确定结果为是，还需要根据特定信息确定出头压缩对象，进而可对头压缩对象进行头压缩处理。
根据特定信息确定出头压缩对象的方式可包括：根据预定义的信息确定出头压缩对象，或者，根据指示信息确定出头压缩对象，或者，根据第一专用信息如profile信息确定出头压缩对象等。
以下即以第一专用信息为以太网帧信息头使用的profile信息为例，通过具体的示例，对本实施例所述方案进行详细说明。
1)示例一
终端设备可根据网络设备配置的profile信息确定出是否需要对以太网帧进行头压缩处理。比如，网络设备可通过无线资源控制(RRC，Radio Resource Control)消息，配置以太网帧信息头使用的profile，即引入新的profile，如在PDCP-config中增加新的IE：
Figure PCTCN2019072001-appb-000008
Figure PCTCN2019072001-appb-000009
其中，profile0x0105为新增加的IE。
终端设备可根据获取到的profile的取值确定是否需要对以太网帧进行头压缩处理，比如，若profile0x0105取值为true，则确定需要对以太网帧进行头压缩处理。
之后，终端设备可根据预定义的信息，确定出头压缩对象。
其中，预定义的信息可以是协议中预先写好的，或者，也可以是网络设备在终端设备初始接入时指示的，或者，还可以是广播中通知的等。
比如，可在协议中写明对以太网帧中属于静态类型的部分进行头压缩处理，即将以太网帧中属于静态类型的部分作为头压缩对象。
再例如，可在协议中写明对各以太网帧格式中共有的且属于静态类型的部分进行头压缩处理。
再比如，可在协议中写明对各以太网帧格式中共有的部分进行头压缩处理。
再比如，可在协议中写明对以太网帧格式或各以太网帧格式中的哪些子域进行头压缩处理。可选的，确定哪些子域进行头压缩处理可以根据子域的类型确定。
终端设备确定出头压缩对象之后，可采用相应的压缩方式，如单向U模式(U mode，uni-directional mode)或者双向可靠R模式(R mode，bi-directional reliable mode)或者双向优 化O模式(O mode，bi-directional optimistic mode)，进行头压缩处理，相应的在3种头压缩状态下按照传输情况等进行迁徙。终端设备还可将压缩得到的压缩数据包向下递交，进行PDCP层和/或无线链路控制(RLC，Radio Link Control)等层的处理。
网络设备作为解压缩端，对压缩数据包进行解压缩，将解压缩后的包向上递交。具体地，网络设备可在接收到来自终端设备的压缩数据包后，按照profile和上下文标识(CID，Context ID)(压缩数据包中携带)将压缩数据包映射使用不同的context ID队列，并采用U mode或者R mode或者O mode进行解压缩处理，相应的在3种解压缩状态下按照传输情况等进行迁徙，后续，网络设备还可向终端设备发送头压缩反馈包等。
压缩端和解压缩端的头压缩状态是一一对应的。压缩端和解压缩端分别有3种状态，分别为初始化状态、中间状态和完全状态，代表了头压缩的不同效率(从低到高)。对于压缩端来说，依次称为初始化和更新状态(IR，Initialization and Refresh)、中间状态(FO，First Order)和最高状态(SO，Second Order)，对于解压缩端来说，依次称为没有上下文状态(NC，No Context)、静态上下文状态(SC，Static Context)和完全上下文状态(FC，Full Context)。压缩端和解压缩端按照一定的规则，在这几个状态之间进行迁徙，完成头压缩和解压缩的操作。
在头压缩过程中，可以使用以下几种包格式：IR包(初始化包，包含静态链子头，可选包括可变链子头)、IR-DYN包(包括可变链子头)、分组类型(packet type)0、packet type 1、packet type 2。其中，当没有context时或初始化时(初始状态)，仅在压缩端和解压缩端之间传输IR包。当需要完整变更或者变更部分可变链子头的信息时(中间状态)，在压缩端和解压缩端之间传输IR-DYN包，或者packet type 2。在最高压缩解压缩状态或者context信息无误的情况下(最高状态)，在压缩端和解压缩端之间传输所有类型的包。
在头压缩中，当需要处理静态类型的子头之外的子头时，被压缩的以太网帧头(Ethernet frame header)格式可如下所示(以Ethernet/RTP/UDP/IP为例)：
Figure PCTCN2019072001-appb-000010
Figure PCTCN2019072001-appb-000011
或者，被压缩的以太网帧头格式可如下所示(以Ethernet/RTP/UDP/IP为例)：
Figure PCTCN2019072001-appb-000012
Figure PCTCN2019072001-appb-000013
又或者，被压缩的以太网帧头格式可如下所示(后面不带IP包为例)：
Figure PCTCN2019072001-appb-000014
其中，VLAN域的扩展方案还可以为：
扩展方案1：
Figure PCTCN2019072001-appb-000015
扩展方案2：
Figure PCTCN2019072001-appb-000016
扩展方案3：
Figure PCTCN2019072001-appb-000017
扩展方案4：
Figure PCTCN2019072001-appb-000018
Figure PCTCN2019072001-appb-000019
若仅对以太网帧中的静态类型部分进行头压缩和解压缩，则压缩端和解压缩端仅在两个状态间迁徙：初始化状态和完全状态。
其中，对于压缩端来说，在初始化和更新状态IR和最高状态SO之间进行迁徙，对于解压缩端来说，在没有上下文状态NC和完全上下文状态FC之间进行迁徙。
以U-mode为例，在此情况下，可定义对解压缩端，经过N3中的K3次错误传输，从FC状态迁移到NC状态，如图5所示，图5为本申请实施例提供的状态迁移示意图。
另外，对以太网帧头压缩初始化操作时，可利用IR包进行初始化，使用以太网帧相对应的profile，静态链(static chain)以以太网帧的静态部分(static part)作为结束。
当PDU session或QoS flow或DRB中承载的是以太网帧时，profile信息可以为基于PDU session或QoS flow或DRB进行配置或指示的。可选地，每个承载上承载的PDU session或QoS flow的头压缩对象可以相同，也可以不同。其好处在于增加了头压缩的灵活度，根据不同数据流支持采用不同的头压缩处理。
2)示例二：
终端设备可根据网络设备配置的profile信息确定出是否需要对以太网帧进行头压缩处理。另外，终端设备还可根据网络设备的指示信息确定出头压缩对象，如可根据专用信令指示信息的指示确定出头压缩对象。专用信令可以是RRC信令、媒体访问控制控制元素(MAC CE，Media Access Control Control Element)或下行控制信息(DCI，Downlink Control Information)等。专用信令可以跟其他头压缩配置一起下发，也可以是一种新的配置/指示信息。
当PDU session或QoS flow或DRB中承载的是以太网帧时，专用信令可以为基于PDU session或QoS flow或DRB进行配置或指示的。可选地，每个承载上承载的PDU session或QoS flow的头压缩对象可以相同，也可以不同。其好处在于增加了头压缩的灵活度，根据不同数据流支持采用不同的头压缩处理。
比如，可引入新的profile，如在PDCP-config中增加新的IE：
Figure PCTCN2019072001-appb-000020
Figure PCTCN2019072001-appb-000021
其中，profile0x0105和ObjectEthernet为新增的IE。
终端设备可根据获取到的profile的取值确定是否需要对以太网帧进行头压缩处理，比如，若profile0x0105取值为true，则可确定需要对以太网帧进行头压缩处理。
之后，终端设备可根据ObjectEthernet的取值确定出头压缩对象，比如，当取值为“static”时，表示将以太网帧中属于静态类型的部分作为头压缩对象，当取值为“all”时，表示将以太网帧中的各不同类型部分均作为头压缩对象。当然，也可以为其它取值，用于指示不同的头压缩对象。另外，ObjectEthernet的取值的格式不限于“static”、“all”这种形式，还可以为其它形式，如option1、option2、option3等，不同的option代表不同的头压缩对象，比如，option1代表第一类头压缩对象，即各以太网帧格式中共有的且属于静态类型的部分。
终端设备确定出头压缩对象之后，后续如何进行头压缩处理以及网络设备如何进行解压缩等可参照示例一中的相关说明，不再赘述。
另外，被压缩的以太网帧头格式以及压缩端和解压缩端对以太网帧头的压缩状态说明、初始化说明等也请参照示例一中的相关说明，不再赘述。
本示例中，可根据网络设备的指示修改压缩力度和效率，增加了头压缩处理的灵活性。
3)示例三：
网络设备可通过RRC消息，配置以太网帧信息头使用的多个profile信息，不同的profile信息可代表不同的头压缩对象。同时，终端设备可根据profile信息确定出是否需要对以太网帧进行头压缩处理。
当PDU session或QoS flow或DRB中承载的是以太网帧时，profile信息可以为基于PDU session或QoS flow或DRB进行配置或指示的。可选地，每个承载上承载的PDU session或QoS flow的头压缩对象可以相同，也可以不同。其好处在于增加了头压缩的灵活度，根据不同数据流支持采用不同的头压缩处理。
比如，可引入新的profile，如在PDCP-config中增加新的IE：
Figure PCTCN2019072001-appb-000022
Figure PCTCN2019072001-appb-000023
其中，profile0x0105、profile0x0106、profile0x0107、profile0x0108、profile0x0115、profile0x0116、profile0x0117和profile0x0118为新增的IE，其各自代表的头压缩对象等可如下表所示。
Profile Identifier Usage Reference
0x0105 Ethernet static class RFC 3095,RFC 4815
0x0106 Ethernet/VLAN static class RFC 3095,RFC 4815
0x0107 Ethernet RFC 3095,RFC 4815
0x0108 Ethernet/VLAN RFC 3095,RFC 4815
0x0115 Ethernet static class RFC 5225
0x0116 Ethernet/VLAN static class RFC 5225
0x0117 Ethernet RFC 5225
0x0118 Ethernet/VLAN RFC 5225
表6 不同profile代表的头压缩对象
如上表所示，若终端设备获取到的profile为profile0x0105，取值为true，则可确定需要对 以太网帧进行头压缩处理，同时可确定出对应的头压缩对象为“Ethernet static class”，即将以太网帧中属于静态类型的部分作为头压缩对象，同时参考的RFC协议为RFC3095等，“Ethernet/VLAN static class”代表的头压缩对象为以太网帧中属于静态类型的部分以及VLAN子头中属于静态类型的部分，“Ethernet”代表的头压缩对象为以太网帧中所有属于不同类型的部分。
需要说明的是，上表中所示的头压缩对象仅为举例说明，并不用于限制本申请的技术方案，在实际应用中，可根据实际需要，有更多粒度的profile定义，分别指示不同的头压缩对象或头压缩粒度等。
终端设备确定出头压缩对象之后，后续如何进行头压缩处理以及网络设备如何进行解压缩等可参照示例一中的相关说明，不再赘述。
另外，被压缩的以太网帧头格式以及压缩端和解压缩端对以太网帧头的压缩状态说明、初始化说明等也请参照示例一中的相关说明，不再赘述。
本示例中，可利用profile的不同，指示不同的压缩力度和效率，增加了头压缩处理的灵活性。
以上是以终端设备作为压缩端，网络设备作为解压缩端为例进行说明，若网络设备为压缩端，终端设备为解压缩端，处理方式类似，网络设备可根据所作配置或者来自核心网的配置确定出是否需要对以太网帧进行头压缩处理并确定出头压缩对象，进而可对确定出的头压缩对象进行头压缩处理，并可将得到的压缩数据包传输给终端设备进行解压缩等，具体实现可参照前述相关说明，不再赘述。
总之，采用本申请实施例所述方案，可实现以太网帧的头压缩，从而节省了空口资源，提升了数据传输效率等。
以上是关于方法实施例的介绍，以下通过装置实施例，对本申请所述方案进行进一步说明。
图6为本申请实施例提供的以太网帧头压缩处理装置的示意性结构图。如图6所示，包括：确定单元601以及压缩单元602。
确定单元601，用于根据配置信息确定需要对以太网帧进行头压缩处理，根据特定信息确定出以太网帧中的头压缩对象。
压缩单元602，用于对头压缩对象进行头压缩处理。
确定单元601可根据第一专用信息确定出需要对以太网帧进行头压缩处理，还可根据特定信息确定出头压缩对象，进而可对头压缩对象进行头压缩处理。
其中，根据特定信息确定出头压缩对象的方式可包括：根据预定义的信息确定出头压缩对象，或者，根据指示信息确定出头压缩对象，或者，根据第一专用信息确定出头压缩对象等。
第一专用信息可包括：以太网帧信息头使用的profile信息。
根据指示信息确定出头压缩对象，可以是指根据专用信令指示信息的指示确定出头压缩对象。根据第一专用信息确定出头压缩对象，可以是指确定出配置的profile信息对应的头压缩对象，不同的profile信息代表不同的头压缩对象。
确定出的头压缩对象可至少包括以下之一：
第一类头压缩对象，第一类头压缩对象中包括：不同以太网帧格式中共有的且属于静态类型的部分；
第二类头压缩对象，第二类头压缩对象中包括：不同以太网帧格式中共有的部分；
第三类头压缩对象，第三类头压缩对象中包括：第一类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
第四类头压缩对象，第四类头压缩对象中包括：第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
第五类头压缩对象，第五类头压缩对象中包括：以太网帧中所有属于不同类型的部分；
第六类头压缩对象，第六类头压缩对象中包括：不同以太网帧格式中共有的且属于第一类型的部分；
第七类头压缩对象，第七类头压缩对象中包括：第六类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分；
第八类头压缩对象，第八类头压缩对象中包括：第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分。
另外，当以太网帧中包含VLAN子头时，上述各类头压缩对象中还可至少包括以下之一：
VLAN子头中属于静态类型的部分；
VLAN子头中属于第一类型的部分；
VLAN子头中所有属于不同类型的部分。
在上述基础上，还可采用以下处理方式：padding部分在压缩后的以太网帧中不传输，以提升传输效率，后续，解压缩时自动补齐padding部分，和/或，以太网帧中的preamble、SFD、FCS不在5G系统内传输，可不对以太网帧中的preamble、SFD和/或FCS进行头压缩等。
不同格式的以太网帧存在共有的部分，同时，不同格式的以太网帧也有其特定的部分。根据不同以太网帧格式中的子头的传输特性等，可以将不同子头归入不同的类型。
所述不同类型可至少包括以下之一：static类型、static-def类型、static-known类型，changing类型和inferred类型等。
其中，static类型、static-def类型和static-known类型可统称为静态类型，inferred类型、static类型、static-def类型和static-known类型可统称为第一类型。
上述各类头压缩对象中，属于静态类型的部分，通常至少包括以下类型之一：static类型、static-def类型、static-known类型。同样地，属于第一类型的部分，通常至少包括以下类型之一：inferred类型、static类型、static-def类型、static-known类型。
图6所示装置实施例的具体工作方式请参照上述方法实施例中的相关说明，不再赘述。
另外，图6所示装置可应用于终端设备中，也可应用于网络设备中。当应用于终端设备中时，可获取网络设备配置的profile信息和/或网络设备的指示信息。
图7为本申请实施例提供的通信设备600的示意性结构图。图7所示的通信设备600包括处理器610，处理器610可以从存储器620中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图7所示，通信设备600还可以包括存储器620。其中，处理器610可以从存储器620中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器620可以是独有于处理器610的一个单独的器件，也可以集成在处理器610中。
可选地，如图7所示，通信设备600还可以包括收发器630，处理器610可以控制该收发器630与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。
其中，收发器630可以包括发射机和接收机。收发器630还可以进一步包括天线，天线的数量可以为一个或多个。
可选地，该通信设备600具体可为本申请实施例的网络设备，并且该通信设备600可以实现本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该通信设备600具体可为本申请实施例的移动终端/终端设备，并且该通信设备600可以实现本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
图8为本申请实施例提供的芯片700的示意性结构图。图8所示的芯片700包括处理器710，处理器710可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图8所示，芯片700还可以包括存储器720。其中，处理器710可以从存储器720中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器720可以是独有于处理器710的一个单独的器件，也可以集成在处理器710中。
可选地，该芯片700还可以包括输入接口730。其中，处理器710可以控制该输入接口730与其他设备或芯片进行通信，具体地，可以获取其他设备或芯片发送的信息或数据。
可选地，该芯片700还可以包括输出接口740。其中，处理器710可以控制该输出接口740与其他设备或芯片进行通信，具体地，可以向其他设备或芯片输出信息或数据。
可选地，该芯片可应用于本申请实施例中的网络设备，并且该芯片可以实现本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该芯片可应用于本申请实施例中的移动终端/终端设备，并且该芯片可以实现本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
图9为本申请实施例提供的通信系统800的示意性框图。如图9所示，该通信系统800包括终端设备810和网络设备820。
其中，该终端设备810可以用于实现上述方法中由终端设备实现的相应的功能，以及该网络设备820可以用于实现上述方法中由网络设备实现的相应的功能，为了简洁，在此不再赘述。
应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)、专用集成电路(ASIC，Application Specific Integrated Circuit)、现成可编程门阵列(FPGA，Field Programmable Gate Array)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read-Only Memory)、可编程只读存储器(PROM，Programmable ROM)、可擦除可编程只读存储器(EPROM，Erasable PROM)、电可擦除可编程只读存储器(EEPROM，Electrically EPROM)或闪存。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，比如静态随机存取存储器(SRAM，Static RAM)、动态随机存取存储器(DRAM，Dynamic RAM)、同步动态随机存取存储器(SDRAM，Synchronous DRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM，Double Data Rate SDRAM)、增强型同步动态随机存取存储器(ESDRAM，Enhanced SDRAM)、同步连接动态随机存取存储器(SLDRAM，Synchlink DRAM)和直接内存总线随机存取存储器(DR RAM，Direct Rambus RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。
可选的，该计算机可读存储介质可应用于本申请实施例中的网络设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机可读存储介质可应用于本申请实施例中的移动终端/终端设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序产品，包括计算机程序指令。
可选的，该计算机程序产品可应用于本申请实施例中的网络设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序产品可应用于本申请实施例中的移动终端/终端设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序。
可选的，该计算机程序可应用于本申请实施例中的网络设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序可应用于本申请实施例中的移动终端/终端设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由移动终端/终端设备实现的相应流程，为了简洁，在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。比如，以上所描述的装置实施例仅仅是示意性的，比如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，比如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独有的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (31)

  1. 一种以太网帧头压缩处理方法，其特征在于，包括：
    第一设备根据配置信息确定需要对以太网帧进行头压缩处理；
    所述第一设备根据特定信息确定出所述以太网帧中的头压缩对象；
    所述第一设备对所述头压缩对象进行头压缩处理。
  2. 根据权利要求1所述的方法，其特征在于，
    所述根据特定信息确定出头压缩对象包括：
    根据预定义的信息确定出头压缩对象；
    或者，根据指示信息确定出头压缩对象；
    或者，根据第一专用信息确定出头压缩对象。
  3. 根据权利要求2所述的方法，其特征在于，
    所述第一专用信息包括：以太网帧信息头使用的配置profile信息。
  4. 根据权利要求2所述的方法，其特征在于，
    所述第一设备包括：终端设备或网络设备；
    该方法进一步包括：当所述第一设备为终端设备时，所述终端设备获取所述网络设备配置的第一专用信息和/或网络设备的指示信息。
  5. 根据权利要求1～4中任一项所述的方法，其特征在于，
    所述第一设备根据配置信息确定需要对以太网帧进行头压缩处理包括：
    所述第一设备根据第一专用信息确定需要对以太网帧进行头压缩处理。
  6. 根据权利要求2所述的方法，其特征在于，
    所述根据指示信息确定出头压缩对象包括：
    根据专用信令指示信息的指示确定出头压缩对象。
  7. 根据权利要求3所述的方法，其特征在于，
    所述根据第一专用信息确定出头压缩对象包括：
    确定出配置的profile信息对应的头压缩对象，不同的profile信息代表不同的头压缩对象。
  8. 根据权利要求1～7中任一项所述的方法，其特征在于，
    所述头压缩对象至少包括以下之一：
    第一类头压缩对象，所述第一类头压缩对象中包括：不同以太网帧格式中共有的且属于静态类型的部分；
    第二类头压缩对象，所述第二类头压缩对象中包括：不同以太网帧格式中共有的部分；
    第三类头压缩对象，所述第三类头压缩对象中包括：所述第一类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
    第四类头压缩对象，所述第四类头压缩对象中包括：所述第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
    第五类头压缩对象，所述第五类头压缩对象中包括：以太网帧中所有属于不同类型的部分；
    第六类头压缩对象，所述第六类头压缩对象中包括：不同以太网帧格式中共有的且属于第一类型的部分；
    第七类头压缩对象，所述第七类头压缩对象中包括：所述第六类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分；
    第八类头压缩对象，所述第八类头压缩对象中包括：所述第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分。
  9. 根据权利要求8所述的方法，其特征在于，
    当以太网帧中包含虚拟局域网VLAN子头时，各类头压缩对象中还至少包括以下之一：
    所述VLAN子头中属于静态类型的部分；
    所述VLAN子头中属于第一类型的部分；
    所述VLAN子头中所有属于不同类型的部分。
  10. 根据权利要求8所述的方法，其特征在于，
    所述不同类型至少包括以下之一：静态static类型、静态定义static-def类型、静态获知static-known类型，可变changing类型以及推断inferred类型。
  11. 根据权利要求8所述的方法，其特征在于，
    所述静态类型至少包括以下之一：静态static类型、静态定义static-def类型、静态获知static-known类型。
  12. 根据权利要求8所述的方法，其特征在于，
    所述第一类型至少包括以下之一：inferred类型、静态static类型、静态定义static-def类型、静态获知static-known类型。
  13. 根据权利要求1～7中任一项所述的方法，其特征在于，
    该方法进一步包括：
    补充padding部分在压缩后的以太网帧中不传输；
    和/或，不对以太网帧中的前导字符preamble、帧开始定界符SFD和/或帧校验序列FCS进行头压缩。
  14. 根据权利要求1～7中任一项所述的方法，其特征在于，
    该方法进一步包括：当协议数据单元会话PDU session或服务质量流QoS flow或无线承载DRB中承载的是以太网帧时，确定基于PDU session或QoS flow或DRB进行以太网帧的头压缩处理。
  15. 一种以太网帧头压缩处理装置，其特征在于，包括：确定单元以及压缩单元；
    所述确定单元，用于根据配置信息确定需要对以太网帧进行头压缩处理，根据特定信息确定出所述以太网帧中的头压缩对象；
    所述压缩单元，用于对所述头压缩对象进行头压缩处理。
  16. 根据权利要求15所述的装置，其特征在于，
    所述确定单元根据第一专用信息确定需要对以太网帧进行头压缩处理。
  17. 根据权利要求15所述的装置，其特征在于，
    所述确定单元根据预定义的信息确定出头压缩对象；
    或者，所述确定单元根据指示信息确定出头压缩对象；
    或者，所述确定单元根据第一专用信息确定出头压缩对象。
  18. 根据权利要求16或17所述的装置，其特征在于，
    所述第一专用信息包括：以太网帧信息头使用的配置profile信息。
  19. 根据权利要求17所述的装置，其特征在于，
    所述确定单元根据专用信令指示信息的指示确定出头压缩对象。
  20. 根据权利要求18所述的装置，其特征在于，
    所述确定单元确定出配置的profile信息对应的头压缩对象，不同的profile信息代表不同的头压缩对象。
  21. 根据权利要求15～20中任一项所述的装置，其特征在于，
    所述头压缩对象至少包括以下之一：
    第一类头压缩对象，所述第一类头压缩对象中包括：不同以太网帧格式中共有的且属于静态类型的部分；
    第二类头压缩对象，所述第二类头压缩对象中包括：不同以太网帧格式中共有的部分；
    第三类头压缩对象，所述第三类头压缩对象中包括：所述第一类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
    第四类头压缩对象，所述第四类头压缩对象中包括：所述第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于静态类型的部分；
    第五类头压缩对象，所述第五类头压缩对象中包括：以太网帧中所有属于不同类型的部分；
    第六类头压缩对象，所述第六类头压缩对象中包括：不同以太网帧格式中共有的且属于第 一类型的部分；
    第七类头压缩对象，所述第七类头压缩对象中包括：所述第六类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分；
    第八类头压缩对象，所述第八类头压缩对象中包括：所述第二类头压缩对象，以及，不同以太网帧格式中各自独有的属于第一类型的部分。
  22. 根据权利要求21所述的装置，其特征在于，
    当以太网帧中包含虚拟局域网VLAN子头时，各类头压缩对象中还至少包括以下之一：
    所述VLAN子头中属于静态类型的部分；
    所述VLAN子头中属于第一类型的部分；
    所述VLAN子头中所有属于不同类型的部分。
  23. 根据权利要求21所述的装置，其特征在于，
    所述不同类型至少包括以下之一：静态static类型、静态定义static-def类型、静态获知static-known类型，可变changing类型以及推断inferred类型。
  24. 根据权利要求21所述的装置，其特征在于，
    所述静态类型至少包括以下之一：静态static类型、静态定义static-def类型、静态获知static-known类型。
  25. 根据权利要求21所述的装置，其特征在于，
    所述第一类型至少包括以下之一：inferred类型、静态static类型、静态定义static-def类型、静态获知static-known类型。
  26. 根据权利要求15～20中任一项所述的装置，其特征在于，
    所述压缩单元进一步用于，
    将补充padding部分在压缩后的以太网帧中不传输；
    和/或，不对以太网帧中的前导字符preamble、帧开始定界符SFD和/或帧校验序列FCS进行头压缩。
  27. 一种通信设备，其特征在于，包括：处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求1至14中任一项所述的方法。
  28. 一种芯片，其特征在于，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求1至14中任一项所述的方法。
  29. 一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至14中任一项所述的方法。
  30. 一种计算机程序产品，其特征在于，包括计算机程序指令，所述计算机程序指令使得计算机执行如权利要求1至14中任一项所述的方法。
  31. 一种计算机程序，其特征在于，所述计算机程序使得计算机执行如权利要求1至14中任一项所述的方法。
PCT/CN2019/072001 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序 WO2020147039A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202110407372.6A CN113115361B (zh) 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序
EP19910588.3A EP3860075B1 (en) 2019-01-16 2019-01-16 Ethernet frame header compression processing method, device and chip and computer program
CN201980054339.0A CN112585923A (zh) 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序
PCT/CN2019/072001 WO2020147039A1 (zh) 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序
US17/232,969 US11736977B2 (en) 2019-01-16 2021-04-16 Method for header compression of ethernet frame, terminal device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/072001 WO2020147039A1 (zh) 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/232,969 Continuation US11736977B2 (en) 2019-01-16 2021-04-16 Method for header compression of ethernet frame, terminal device

Publications (1)

Publication Number Publication Date
WO2020147039A1 true WO2020147039A1 (zh) 2020-07-23

Family

ID=71613495

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/072001 WO2020147039A1 (zh) 2019-01-16 2019-01-16 以太网帧头压缩处理方法、装置、芯片及计算机程序

Country Status (4)

Country Link
US (1) US11736977B2 (zh)
EP (1) EP3860075B1 (zh)
CN (2) CN112585923A (zh)
WO (1) WO2020147039A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110971363B (zh) * 2018-09-28 2022-03-08 华为技术有限公司 用于以太网数据的通信方法的方法和装置
US20220116325A1 (en) * 2021-12-22 2022-04-14 Intel Corporation Packet format adjustment technologies

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102025737A (zh) * 2010-12-09 2011-04-20 中兴通讯股份有限公司 微波通信中以太网数据包压缩、传输方法和压缩机、系统
US20160359739A1 (en) * 2015-06-03 2016-12-08 Broadcom Corporation Apparatus and Method for Packet Header Compression

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1958072A4 (en) * 2005-12-08 2012-05-02 Intel Corp COMPRESSION / DECOMPRESSION SOFTWARE
US8243757B2 (en) * 2007-07-05 2012-08-14 Ceragon Networks Ltd. MAC header compression using a pointer
EP2043313B1 (en) * 2007-09-28 2013-08-14 Alcatel Lucent Circuit emulation service method and telecommunication system for implementing the method
WO2010012998A1 (en) * 2008-07-30 2010-02-04 British Telecommunications Public Limited Company Header compression scheme
CN102045132B (zh) * 2009-10-23 2014-04-30 华为技术有限公司 基于重传机制的对头压缩数据包进行传输的方法和装置
JP6015304B2 (ja) * 2012-09-27 2016-10-26 富士通株式会社 通信装置およびアドレス学習方法
CN103825869A (zh) * 2012-11-19 2014-05-28 中兴通讯股份有限公司 以太网报文头的压缩及解压缩方法、压缩及解压缩设备
FR3006534B1 (fr) * 2013-05-31 2015-05-22 Thales Sa Procedes de transmission et de reception de donnees entre un terminal et une passerelle, en particulier via une liaison satellite
US9769701B2 (en) * 2013-06-14 2017-09-19 Texas Instruments Incorporated Header compression for wireless backhaul systems
CN104079488B (zh) * 2014-07-22 2017-03-29 武汉虹信通信技术有限责任公司 基于以太网二层头压缩的传输设备及方法
US11006316B2 (en) * 2017-10-16 2021-05-11 Ofinno, Llc Header compression for ethernet frame
CN110958646B (zh) * 2018-09-27 2023-03-31 华为技术有限公司 通信方法与设备
AU2018443582B2 (en) * 2018-09-28 2022-10-27 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Communication method, terminal device, and network device
CN109218995B (zh) * 2018-10-08 2021-08-20 腾讯科技（深圳）有限公司 通信方法、装置、计算机可读介质及电子设备
WO2020077543A1 (zh) * 2018-10-16 2020-04-23 Oppo广东移动通信有限公司 一种处理帧头的方法及装置、通信设备
WO2020097855A1 (zh) * 2018-11-15 2020-05-22 Oppo广东移动通信有限公司 无线通信的方法和通信设备
EP3891948A1 (en) * 2018-12-20 2021-10-13 Huawei Technologies Co., Ltd. Device and method for flexible frame compression
CN111869183A (zh) * 2019-02-14 2020-10-30 联发科技股份有限公司 简单的以太网报头压缩

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102025737A (zh) * 2010-12-09 2011-04-20 中兴通讯股份有限公司 微波通信中以太网数据包压缩、传输方法和压缩机、系统
US20160359739A1 (en) * 2015-06-03 2016-12-08 Broadcom Corporation Apparatus and Method for Packet Header Compression

Also Published As

Publication number Publication date
EP3860075A4 (en) 2021-11-10
CN113115361B (zh) 2023-03-10
CN112585923A (zh) 2021-03-30
US20210243647A1 (en) 2021-08-05
US11736977B2 (en) 2023-08-22
EP3860075A1 (en) 2021-08-04
EP3860075B1 (en) 2023-03-01
CN113115361A (zh) 2021-07-13

Similar Documents

Publication Publication Date Title
US20190230682A1 (en) Data transmission method, apparatus, and system
WO2020107751A1 (zh) 一种数据传输方法及装置、终端
WO2020155115A1 (zh) 一种头压缩的处理方法及装置、通信设备
WO2021218888A1 (zh) 通信方法和装置
WO2020015727A1 (zh) 路径选择的方法、终端设备和网络设备
WO2020063318A1 (zh) 通信方法与设备
WO2020220328A1 (zh) 无线通信的方法和设备
WO2020051745A1 (zh) 一种数据传输方法及装置、通信设备
WO2020147039A1 (zh) 以太网帧头压缩处理方法、装置、芯片及计算机程序
WO2020078248A1 (zh) 无线通信方法及设备
WO2020015733A1 (zh) D2d通信的方法和终端设备
WO2021185058A1 (zh) 一种中继通信方法及相关设备
US8315192B2 (en) Method and system for configuring a media access control header to reduce a header overhead
WO2021012260A1 (zh) 用于传输数据的方法、发送端设备和接收端设备
WO2020198966A1 (zh) 无线通信的方法和设备
WO2020199030A1 (zh) 一种压缩处理方法、解压缩处理方法及相关设备
WO2020010619A1 (zh) 数据传输方法、终端设备和网络设备
WO2020077543A1 (zh) 一种处理帧头的方法及装置、通信设备
WO2018053685A1 (zh) 数据封装方法、装置以及通信系统
WO2018045521A1 (zh) 无线网络中传输信令的方法和装置
WO2021087729A1 (zh) 一种指示解压缩对象的方法及装置、通信设备
WO2020087546A1 (zh) 一种网络信息传输方法、获取方法、网络设备及终端设备
TW202021329A (zh) 通訊方法、終端設備和網路設備
WO2020118722A1 (zh) 一种数据处理方法、设备及存储介质
WO2020082381A1 (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: 19910588

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019910588

Country of ref document: EP

Effective date: 20210426

NENP Non-entry into the national phase

Ref country code: DE