EP3874715A1 - 5g nr methods for ethernet header compression - Google Patents
5g nr methods for ethernet header compressionInfo
- Publication number
- EP3874715A1 EP3874715A1 EP19880503.8A EP19880503A EP3874715A1 EP 3874715 A1 EP3874715 A1 EP 3874715A1 EP 19880503 A EP19880503 A EP 19880503A EP 3874715 A1 EP3874715 A1 EP 3874715A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- ethernet
- header
- destination
- ethernet header
- packet
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
- 230000006835 compression Effects 0.000 title claims description 48
- 238000007906 compression Methods 0.000 title claims description 48
- 238000000034 method Methods 0.000 title abstract description 7
- 230000005540 biological transmission Effects 0.000 claims abstract description 28
- 238000013507 mapping Methods 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 18
- 230000015654 memory Effects 0.000 claims description 16
- 230000011664 signaling Effects 0.000 claims description 11
- 230000006837 decompression Effects 0.000 claims description 5
- 230000006978 adaptation Effects 0.000 claims description 2
- 230000004044 response Effects 0.000 claims 3
- 102100022734 Acyl carrier protein, mitochondrial Human genes 0.000 claims 1
- 101000678845 Homo sapiens Acyl carrier protein, mitochondrial Proteins 0.000 claims 1
- 230000001419 dependent effect Effects 0.000 claims 1
- 238000004891 communication Methods 0.000 description 36
- 230000006870 function Effects 0.000 description 13
- 238000007726 management method Methods 0.000 description 5
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000005291 magnetic effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 101150069124 RAN1 gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003595 spectral effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- 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
- Embodiments pertain to radio access networks (RANs). Some embodiments relate to cellular networks, including Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), 4 th generation (4G) and 5 th generation (5G) New Radio (NR) (or next generation (NG)) networks. Some embodiments relate to the use of ethemet protocols in NG networks.
- 3GPP Third Generation Partnership Project
- LTE Long Term Evolution
- 4G 4 th generation
- 5G 5 th generation
- NR New Radio
- NG next generation
- NG systems are expected to have a unified framework in which different and sometimes conflicting performance criteria and services are to be met. In general, NG systems will evolve based on 3 GPP LTE-Advanced technology with additional enhanced radio access technologies (RATs) and functionalities to enable seamless wireless connectivity solutions.
- RATs enhanced radio access technologies
- TSN Time Sensitive Networking
- FIG. 1 illustrates combined communication system in accordance with some embodiments.
- FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
- FIG. 3 illustrates Ethernet header compression and Robust Header Compression (ROHC) in accordance with some embodiments.
- FIG. 4 illustrates a Data Convergence Protocol (PDCP) entity in accordance with some embodiments.
- PDCP Data Convergence Protocol
- FIG. 5 illustrates a mapping between connection identity and
- Ethernet header fields in accordance with some embodiments.
- FIG. 6 illustrates an uncompressed Ethernet header format in accordance with some embodiments.
- FIG. 7 illustrates a compressed Ethernet header format in accordance with some embodiments.
- FIG. 8 illustrates another compressed Ethernet header format in accordance with some embodiments.
- FIG. 9 illustrates payload content in accordance with some embodiments.
- FIG. 10 illustrates messaging in accordance with some embodiments.
- FIG. 1 illustrates a combined communication system in accordance with some embodiments.
- the system 100 includes 3GPP LTE/4G and NG network functions.
- a network function can be implemented as a discrete network element on a dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., dedicated hardware or a cloud infrastructure.
- the evolved packet core (EPC) of the LTE/4G network contains protocol and reference points defined for each entity.
- These core network (CN) entities may include a mobility management entity (MME) 122, serving gateway (S-GW) 124, and paging gateway (P-GW) 126.
- MME mobility management entity
- S-GW serving gateway
- P-GW paging gateway
- the control plane and the user plane may be separated, which may permit independent scaling and distribution of the resources of each plane.
- the UE 102 may be connected to either an access network or radio access network (RAN) 110 and/or may be connected to the NG-RAN 130 (gNB) or an Access and Mobility Function (AMF) 142.
- the RAN 110 may be an eNB or a general non-3GPP access point, such as that for Wi-Fi.
- the NG core network may contain multiple network functions besides the AMF 112.
- the UE 102 may generate, encode and perhaps encrypt uplink transmissions to, and decode (and decrypt) downlink transmissions from, the RAN 1 10 and/or gNB 130 (with the reverse being true by the RAN 110/gNB 130).
- the network functions may include a User Plane Function (UPF)
- UPF User Plane Function
- SMF Session Management Function
- PCF Policy Control Function
- AF Application Function
- AUSF Authentication Server Function
- UDM User Data Management
- the AMF 142 may provide UE-based authentication, authorization, mobility management, etc.
- the AMF 142 may be independent of the access technologies.
- the SMF 144 may be responsible for session management and allocation of IP addresses to the UE 102.
- the SMF 144 may also select and control the UPF 146 for data transfer.
- the SMF 144 may be associated with a single session of the UE 102 or multiple sessions of the UE 102. This is to say that the UE 102 may have multiple 5G sessions. Different SMFs may be allocated to each session. The use of different SMFs may permit each session to be individually managed. As a consequence, the functionalities of each session may be independent of each other.
- the UPF 126 may be connected with a data network, with which the UE 102 may communicate, the UE 102 transmitting uplink data to or receiving downlink data from the data network.
- the AF 148 may provide information on the packet flow to the
- the PCF 132 responsible for policy control to support a desired QoS.
- the PCF 132 may set mobility and session management policies for the UE 102. To this end, the PCF 132 may use the packet flow information to determine the appropriate policies for proper operation of the AMF 142 and SMF 144.
- the AUSF 152 may store data for UE authentication.
- the UDM 128 may similarly store the UE subscription data.
- the gNB 130 may be a standalone gNB or a non-standalone gNB, e.g., operating in Dual Connectivity (DC) mode as a booster controlled by the eNB 110 through an X2 or Xn interface. At least some of functionality of the EPC and the NG CN may be shared (alternatively, separate components may be used for each of the combined component shown).
- the eNB 110 may be connected with an MME 122 of the EPC through an SI interface and with a SGW 124 of the EPC 120 through an S l-U interface.
- the MME 122 may be connected with an HSS 128 through an S6a interface while the UDM is connected to the AMF 142 through the N8 interface.
- the SGW 124 may connected with the PGW 126 through an S5 interface (control plane PGW-C through S5-C and user plane PGW-U through S5-U).
- the PGW 126 may serve as an IP anchor for data through the internet.
- the NG CN may contain an AMF 142, SMF 144 and
- the eNB 110 and gNB 130 may communicate data with the SGW 124 of the EPC 120 and the UPF 146 of the NG CN.
- the MME 122 and the AMF 142 may be connected via the N26 interface to provide control information there between, if the N26 interface is supported by the EPC 120.
- the gNB 130 is a standalone gNB, the 5G CN and the EPC 120 may be connected via the N26 interface.
- FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
- the communication device may be a UE (including an loT device and NB-IoT device), eNB, gNB or other equipment used in the 4G/LTE or NG network environment.
- the communication device 200 may be a specialized computer, a personal or laptop computer (PC), a tablet PC, a mobile telephone, a smart phone, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
- the communication device 200 may be embedded within other, non-communication-based devices such as vehicles and appliances.
- Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms.
- Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner.
- circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
- the whole or part of one or more computer systems e.g., a standalone, client or server computer system
- one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
- the software may reside on a machine readable medium.
- the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
- module (and“component”) is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
- modules are temporarily configured, each of the modules need not be instantiated at any one moment in time.
- the modules comprise a general-purpose hardware processor configured using software
- the general-purpose hardware processor may be configured as respective different modules at different times.
- Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
- the communication device 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204 and a static memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208.
- the main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
- the communication device 200 may further include a display unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse).
- a hardware processor 202 e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof
- main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
- the communication device 200 may further
- the display unit 210, input device 212 and UI navigation device 214 may be a touch screen display.
- the communication device 200 may additionally include a storage device (e.g., drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
- GPS global positioning system
- the communication device 200 may further include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
- a serial e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
- USB universal serial bus
- IR infrared
- NFC near field communication
- the storage device 216 may include a non-transitory machine readable medium 222 (hereinafter simply referred to as machine readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein.
- the instructions 224 may also reside, successfully or at least partially, within the main memory 204, within static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200.
- the machine readable medium 222 is illustrated as a single medium, the term "machine readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.
- machine readable medium may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
- Non-limiting machine-readable medium examples may include solid-state memories, and optical and magnetic media.
- machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read- Only- Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks.
- non-volatile memory such as semiconductor memory devices (e.g., Electrically Programmable Read- Only- Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices
- EPROM Electrically Programmable Read- Only- Memory
- EEPROM Electrically Erasable Programmable Read-Only Memory
- flash memory devices e.g., Electrically Erasable Programmable Read-Only Memory (EEPROM)
- EPROM Electrically Programmable Read- Only- Memory
- EEPROM Electrically Erasable Programmable Read-Only Memory
- flash memory devices e.g
- the instructions 224 may further be transmitted or received over a communications network using a transmission medium 226 via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
- Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks. Communications over the networks may include one or more different protocols, such as Institute of Electrical and Electronics
- Wi-Fi Wi-Fi
- WiMax WiMax
- IEEE 802.15.4 family of standards
- LIE Long Term Evolution
- the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the transmission medium 226.
- physical jacks e.g., Ethernet, coaxial, or phone jacks
- antennas to connect to the transmission medium 226.
- the communication device 200 may be an loT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., smart phone, vehicular UE), any which may communicate with the core network via the eNB or gNB shown in FIG. 1.
- the communication device 200 may be an loT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., smart phone, vehicular UE), any which may communicate with the core network via the eNB or gNB shown in FIG. 1.
- the communication device 200 may be an loT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-IoT device (
- the communication device 200 is IoT device, in some embodiments, the
- the communication device 200 may be li ited in memory, size, or functionality, allowing larger numbers to be deployed for a similar cost to smaller numbers of larger devices.
- the communication device 200 may, in some embodiments, be a virtual device, such as an application on a smart phone or other computing device.
- Ethernet header overhead therefore may be reduced to increase packet resource efficiency and reliability, and reduce packet latency. This may also contribute to increased system capacity and improved spectral usage footprint.
- the compression can be applied to one or more (up to all) fields added in the Ethernet protocol, including header (including source/destination address, length/type etc.), and trailer (including padding, frame check sequence etc.).
- header including source/destination address, length/type etc.
- trailer including padding, frame check sequence etc.
- Ethernet protocol is a local area network (LAN) protocol that is in compliance with the IEEE 802.3 LAN standards which supports an IEEE 802.1 Q tag.
- IEEE 802.IQ is IEEE standard that supports virtual LANs (VLANs) on an IEEE 802.3 Ethernet network.
- Portions of the network which are VLAN-aware can include VLAN tags.
- VLAN tags When an Ethernet frame enters the VLAN- aware portion of the network, a tag is added to a Layer 2 packet to represent the VLAN membership.
- the tag contains the tag value, which identifies the data as a tag, and also contains the VLAN ID of the VLAN from which the packet is sent. Note also that although Ethernet headers (and trailers) are described herein, the embodiments may be used in other LAN networks and protocols.
- Ethernet header compression is mainly described for 3 GPP NR standards. The same principle can be applied to 3 GPP LTE standards, or other communication systems.
- the layer 2 user plane protocol stack includes the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) layers.
- SDAP Service Data Adaptation Protocol
- PDCP Packet Data Convergence Protocol
- RLC Radio Link Control
- MAC Medium Access Control
- Ethernet packet compression may be incorporated in the PDCP layer.
- Ethernet packet compression may be incorporated in the SDAP layer, or in a new layer.
- the Ethernet packet may carry a payload with protocols of the combination of Internet Protocol (IP), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), Realtime Transport Protocol (RTP), IP
- IP Internet Protocol
- UDP User Datagram Protocol
- TCP Transmission Control Protocol
- RTP Realtime Transport Protocol
- RTP/ESP/TCP/UDP/IP denotes one of a combination of the protocols, e.g. IP, TCP/IP, UDP/TP, ESP/TP, RTP/UDP/IP.
- Robust Header Compression may be applied to compress the RTP/ESP/TCP/UDP/IP headers.
- FIG. 3 illustrates Ethernet header compression and ROHC in accordance with some embodiments. Compression may be performed by any entity, such as the UE or gNB. For ROHC operation, the starting position of the RTP/ESP/TCP/UDP/IP headers should be known. This can be accomplished, e.g., by performing Ethernet header compression and ROHC separately. Ethernet header compression and ROHC may be similar handling ROHC in the presence of the SDAP layer, where ROHC is aware of the length of the SDAP header (zero bytes or one byte).
- FIG. 4 illustrates a Packet Data Convergence Protocol (PDCP) entity in accordance with some embodiments.
- PDCP Packet Data Convergence Protocol
- FIG. 4 may represent a functional view of the PDCP entity for the PDCP sublayer.
- the PDCP entity may perform header compression at the transmitter side and header decompression at the recei ver side of the Ethernet header, in addition to ROHC.
- Ethernet frames may contain the following fields: Preamble, Start
- the preamble field may permit the Physical Layer Signaling (PLS) circuitry to reach its steady-state synchronization with the received packet’s timing. Given that the preamble is fixed sequence, the field may not be transmitted after compression.
- the SFD field may be a sequence 10101011. This field may also not be transmitted after compression. Compression of the destination address and source address is discussed in more detail below, as will compression of the length/type field and 802. IQ tag.
- the pad(ding) field may be used to satisfy a minimum MAC frame size constraint and can be eliminated if the length of payload is available either via the Ethernet header or packet inspection of the payload.
- the FCS field may be used for error detection and may be eliminated after compression since the lower layers may provide cyclic redundancy check (CRC) detection.
- connection identity may be introduced to represent the pair of a source address and destination address.
- (x, y) is used to denote the pair of a source address x and destination address y.
- a table stored in a memory of each communication device can be used to map the connection ID to the pair of source address and destination address. Entries in the table may be retained until a predetermined condition is met, e.g., the data radio bearer (DRB) to the UE is deactivated.
- DRB data radio bearer
- connection identity may apply for both downlink and uplink communications.
- connection identity n corresponds to a source/destination address pair (x, y) for downlink communications
- same connection identity n may correspond to the source/destination address pair (y, x) in uplink communications.
- connection identity for downlink and uplink communications may be independent. That is, in the independent option, there may be no relationship between the source/destination address pairs associated to the same connection identity for downlink and uplink
- connection ID may be associated with other network functionality.
- the connection ID may also be unique within a DRB. This can increase the usage of connection identities since the same connection identity can be reused across different DRBs to indication different source/destination address pairs.
- connection ID may represent a pair of source address and destination address.
- the connection ID may be used to represent a subset of Ethernet header fields.
- the connection ID can represent the unique combination of the following Ethernet header fields: destination address, source address, type/length, and 802. IQ tag, or a unique combination of the following Ethernet header fields: destination address, source address, and type/length.
- connection ID space in DL and LIL can be independent, which means that the same connection ID can refer to a different unique combination of Ethernet header fields.
- connection identity refers to the
- FIG. 5 illustrates a mapping between connection identity and Ethernet header fields in accordance with some embodiments. For example, when connection identity m is first used and the Ethernet header fields destination address, source address, and type/length are present (while 802. I Q flag is not present), then connection identity m may represent the values of destination address, source address, and type/length when the compressed header is sent (i.e., when such Ethernet header fields are not present). Similarly, when the connection identity n is first used and the Ethernet header fields destination address, source address, type/length, and 802.1 Q flag are present, then connection identity n may represent the values of destination address, source address, type/length, and 802.
- Various embodiments may be used to signal the mapping between connection identity and source/destination address pair.
- the LIE and gNB may use RRC signalling to add, modify, and remove the mapping between connection identity and source/destination address pair.
- the signalling can be added as new fields in information elements (IEs) such as PDCP-Config or DRB- ToAddMod.
- IEs information elements
- mapping may be conveyed using a
- PDCP control packet data unit PDU
- a new PDCP control PDU can be introduced to alter (add, modify, or remove) the mapping between connection identity and source/destination address pair.
- the“PDU type” field for the PDCP control PDU could be 010 or higher values. Note that if Ethernet header compression is performed in SDAP layer, then the mapping relationship can be signaled in a SDAP control PDU. If Ethernet header compression is performed in a new layer, the mapping relationship can be signaled in the control PDU of the corresponding layer.
- mapping may be conveyed within the
- PDCP data PDU This option can be considered as“in-band” signalling.
- Ethernet header compression is performed in SDAP layer
- the mapping relationship can be signaled in SDAP data PDU.
- Ethernet header compression is performed in a new layer, the mapping relationship can be signaled in the control PDU of the corresponding layer.
- FIGS. 6-8 illustrate an Ethernet header format in accordance with some embodiments.
- An example header format for Ethernet header compression includes a connection identity in a first octet.
- the length of the connection identity may be fixed, may be configured by RRC signalling, or may be signaled in the data PDU itself.
- the connection identity has a length of 6 bit connection identity; this value is however merely exemplary, other connection identity lengths may be used.
- the first octet of the header may also include a“Type” field.
- “Type” field may have different values in different examples, in the different embodiments pictured in FIGS. 6-8.
- the“Type” field may have a value of 0 in the embodiment of FIG. 6, 1 in the embodiment of FIG. 7, etc.
- the“Type” field may be 2 bits (the last two bits of the first octet, sharing the first octet with the connection identity); in other embodiments, however, the length of“Type” field may be determined by how many types of headers are supported. In such embodiments, the length of“Type” field may take different values, e.g., 3 bits, 4 bits.
- FIG. 6 illustrates an uncompressed Ethernet header format in accordance with some embodiments.
- multiple fields are contained within the octets of the Ethernet header.
- the Destination Address may be 6 bytes in length and signaled in octets 2-7
- the Source Address may be 6 bytes in length and signaled in octets 8-13
- the Length/type, 802. IQ tag may be signaled in octets 14-19.
- the various fields may thus be signaled as is, without any compression.
- one 802.1 Q tag may be inserted in the Ethernet header. Note that other fields, such as the preamble, SFD, and ECS may not be transmitted.
- Such an uncompressed header can be transmitted when a connection is initially used, e.g., a new'
- the transmitter may include such uncompressed header for one or more packets to increase the reliability.
- the decision for sending uncompressed headers in one or more packets may be configurable and can be made at runtime by the transmitter, e.g., based on the link quality, desired target for reliability, etc.
- FIG. 7 illustrates a compressed Ethernet header format in accordance with some embodiments. As shown in this compressed embodiment, neither the Destination Address nor the Source Address is transmitted.
- FIG. 8 illustrates another compressed Ethernet header format in accordance with some embodiments. As shown in FIG. 8, similar to FIG. 7, transmission of both the Destination Address and the Source Address may be avoided.
- the 802. IQ tag may, in FIGS. 6 and 7, contain a tag protocol identifier (TPID) that has a fixed value for 802. IQ (0x8100).
- TPID tag protocol identifier
- the TPID may be removed from the 802. IQ tag, reducing the size of this field from 4 octets to 2 octets.
- the Length/type field indicates the payload size
- the Length/type field may not be transmitted since it is possible to derive the payload size from lower layers.
- the Length/type field indicates the payload type (i.e., length/type field is EtherType)
- a mapping table from long EtherType (2 bytes) to a short list of IDs can be designed. For example, a 4 bit Short Payload Type field may be used to represent the EtherType.
- value 0 may indicate an IPv4 payload (EtherType 0x0800), while value 1 may indicate IPv6 payload (EtherType 0x86DD).
- a special value (such as 15) can be used to indicate an EtherType not in the mapping table.
- the actual EtherType can follow the Short Payload Type field.
- the Short Payload Type field is not present and only a single 802. IQ tag is inserted.
- the VLAN identifier (VID) in 802. IQ tag may be compressed.
- the VID can be considered as part of the connection identity, together with the Source Address and Destination Address.
- a delta encoding can be introduced for the VID, e.g., to only encode the difference between the current VID and the VID signalling in the previous packet.
- connection identity may represent a unique combination of the Ethernet header fields: destination address, source address, type/length, and optionally 802.1Q tag.
- the transmitter can transmit a compressed header.
- FIG. 9 illustrates payload content in accordance with some embodiments.
- the payload content excludes the PDCP header and Message Authentication Code - Integrity (MAC-I).
- MAC-I Message Authentication Code - Integrity
- Ethernet header fields (Destination/Source Address, Length/type, and optionally 802.1 Q tag) may be represented by the“Connection ID” and therefore may not be present in the PDCP payload.
- a 2 bit“Type” field is shown in FIG. 9; in other embodiments, however the“Type” field may be 1 bit to differentiate between compressed and uncompressed Ethernet header fields.
- the length of“Connection ID” field can be different from that shown, e.g., 7 bits, 15 bits, 14 bits.
- FIGS. 6-9 illustrate only a few non-limiting examples to illustrate the header formats for Ethernet header compression.
- Other combinations/variations of Ethernet header compression may also be used.
- a compressed header format may, in other embodiments, also include a CRC for the original Ethernet header before compression. This may permit the recei ver to be able to verify that the decompression operation is correct.
- a trigger may be used to determine whether the compressed Ethernet headers may be used.
- FIG. 10 illustrates messaging in accordance with some embodiments.
- feedback can be provided from the receiver to the transmitter to indicate the status of receiver side, which may be provided even in an unacknowledged mode (in which data acknowledgement is not transmitted).
- the status may include whether the uncompressed headers have been correctly received.
- the feedback can be transmitted in the PDCP data PDU, utilizing the header format above. In this case, a dedicated Type for feedback can be used.
- the feedback can be sent with a PDCP control PDU, with a new value for“PDU type” to indicate the Ethernet header compression feedback.
- the network can configure the number of transmissions for the feedback for a specific connection identity; the number of transmissions for each connection identity may be independent of the number of transmissions for each other connection identity and may depend, for example, on application or quality of service (QoS) associated with the connection identity.
- the network may configure a criterion to the UE to permit the UE to select the number of transmissions for the feedback.
- the criterion may be based on, for example, the UE’s mobility state, measured reference signal received power (RSRP)/reference signal received quality (RSRQ)/signal-to-interference-plus- noise ratio (SINR) value from the gNB, source/destination address pair, UL/DL direction, and/or desired degree of reliability, among others.
- the configuration can be provided in RRC signalling or in a PDCP control PDU.
- the UE may transmit the feedback for that connection identity after the number of transmissions from the gNB or other entity as configured by the network.
- the UE can transmit compressed header if feedback for the connection identity is received from the gNB or other entity.
- transmission of the compressed header may be initiated from the source without feedback from the destination.
- the UE may transmit a compressed header for the connection after a number of transmissions of the uncompressed header has been completed.
- the number of transmissions of the uncompressed header can be either fixed in the specification (e.g., fixed to 2 or 3) or may be configured by the network.
- the network can configure the number of transmissions of the uncompressed header in RRC signalling or a PDCP control PDU.
- the number of transmissions of the uncompressed header can be configured per UE, per cell group, per DRB, per cell, per link direction (UL or DL) or any combination of above.
- the number of transmissions of the uncompressed header can be defined or configured depending on specific conditions. The conditions, as above, may be based on UE's mobility state, measured RSRP/RSRQ/SINR values, source/destination address pair, UL/DL direction, and/or desired degree of reliability, among others.
- the transmitter may send one or more packets with an uncompressed Ethernet header, followed by packets with a compressed Ethernet header.
- the receiver may optionally send feedback on the successful reception of the uncompressed transmission to trigger follow-up packet transmissions with compressed Ethernet header.
- the network can inform the UE whether to reset the Ethernet header compression operation (e.g., the maintenance of the connection identities). This can be done by RRC signalling, PDCP control PDU etc.
- Ethernet header compression may be enabled for the DRB.
- the field maxCID may be used to configure the maximum number of connection identities. If the field drb-ContinueEthernetCompression is signaled, then the UE may continue the Ethernet header compression operation without resetting the mapping relationship between the connection identities to the source/destination address (and potential other fields like VLAN identifier). Otherwise, the Ethernet header compression operation may be reset as discussed above.
- Ethernet header compression may be configured independently for DL and UL transmissions in a DRB.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862753779P | 2018-10-31 | 2018-10-31 | |
US201962824905P | 2019-03-27 | 2019-03-27 | |
PCT/US2019/059177 WO2020092780A1 (en) | 2018-10-31 | 2019-10-31 | 5g nr methods for ethernet header compression |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3874715A1 true EP3874715A1 (en) | 2021-09-08 |
EP3874715A4 EP3874715A4 (en) | 2022-08-03 |
Family
ID=70463325
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP19880503.8A Withdrawn EP3874715A4 (en) | 2018-10-31 | 2019-10-31 | 5g nr methods for ethernet header compression |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP3874715A4 (en) |
WO (1) | WO2020092780A1 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113541910B (en) * | 2019-02-01 | 2023-03-31 | Oppo广东移动通信有限公司 | Processing method and device for header compression |
CN112351459A (en) * | 2019-08-09 | 2021-02-09 | 夏普株式会社 | Execution method of transmitting end/receiving end of PDCP entity, PDCP entity and communication equipment |
US11849011B2 (en) | 2022-01-31 | 2023-12-19 | Nokia Solutions And Networks Oy | Enabling ethernet communication over IP transport |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IL162305A (en) * | 2004-06-02 | 2010-06-16 | Eci Telecom Ltd | Method, device and system for transmitting ethernet packets |
US9515925B2 (en) * | 2011-05-19 | 2016-12-06 | Qualcomm Incorporated | Apparatus and methods for media access control header compression |
US9294589B2 (en) * | 2011-06-22 | 2016-03-22 | Telefonaktiebolaget L M Ericsson (Publ) | Header compression with a code book |
US9769701B2 (en) * | 2013-06-14 | 2017-09-19 | Texas Instruments Incorporated | Header compression for wireless backhaul systems |
KR101724231B1 (en) * | 2016-04-27 | 2017-04-06 | 건국대학교 산학협력단 | Method and apparatus for improving network transfer efficiency by compressing ethernet header |
-
2019
- 2019-10-31 EP EP19880503.8A patent/EP3874715A4/en not_active Withdrawn
- 2019-10-31 WO PCT/US2019/059177 patent/WO2020092780A1/en unknown
Also Published As
Publication number | Publication date |
---|---|
WO2020092780A1 (en) | 2020-05-07 |
EP3874715A4 (en) | 2022-08-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10813086B2 (en) | Bearer mobility and splitting in a radio access network-based, 3rd generation partnership project network having an integrated wireless local area network | |
CN110431859B (en) | Method for interaction between layers in wireless communication system and apparatus therefor | |
CN107005841B (en) | System, method and device for direct device-to-device communication using encapsulation | |
US8588227B2 (en) | Recursive header compression for relay nodes | |
US11737128B2 (en) | Wireless communications system, base station, mobile station, and processing method | |
EP2941043B1 (en) | Method, device, and system for multi-standard network convergence | |
CN111587589A (en) | Method for protocol enhancement in 5G NAS | |
WO2017172912A1 (en) | Method and apparatus for clot device data transfer | |
US11723088B2 (en) | E1 interface setup in NG-RAN | |
US20120155375A1 (en) | Method and Apparatus for Header Compression in Network Relay Scenario | |
EP2918136A1 (en) | Os level wlan/cellular aggregation for integrated femto and ap deployments | |
US20170222943A1 (en) | Method and apparatus for reordering | |
WO2020092780A1 (en) | 5g nr methods for ethernet header compression | |
CN111869183A (en) | Simple Ethernet header compression | |
WO2020036928A1 (en) | Service data flow awareness for latency reduction | |
WO2017216510A1 (en) | Providing service data flow description | |
US20150223107A1 (en) | User equipment and method for application specific packet filter | |
CN112585925A (en) | Method and apparatus for wireless communication | |
WO2018031081A1 (en) | Systems and methods for packet data convergence protocol sequencing | |
WO2023017052A1 (en) | Technique for quality of service indication and compliance of application data units | |
CN108471633B (en) | Communication method and communication system | |
CN111373834B (en) | Client device, access network device, method and computer program for establishing a data radio bearer | |
WO2015176208A1 (en) | Data packet forwarding processing method and device | |
WO2019092244A1 (en) | Core network routing of application data | |
WO2019092059A1 (en) | Application data in control messages |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20201204 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Free format text: PREVIOUS MAIN CLASS: H04L0029060000 Ipc: H04W0028060000 |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20220704 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 69/324 20220101ALI20220628BHEP Ipc: H04L 69/22 20220101ALI20220628BHEP Ipc: H04L 69/04 20220101ALI20220628BHEP Ipc: H04W 28/06 20090101AFI20220628BHEP |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN |
|
18W | Application withdrawn |
Effective date: 20240307 |