Apparatus, circuitry, and method of processing data frames for use in a wireless communication network

Abstract

The present application relates to apparatus, circuitry and methods of processing data frames for use in a wireless communication network. A method of processing data frames for transmission over a wireless access interface of a wireless communication system, the method comprising receiving a first data frame comprising a first protocol header associated with a media access control (MAC) frame format for data transmission within a local area network (LAN); applying header compression to the first data frame by compressing one or more protocol header fields of the first protocol header in accordance with a header compression context to form a first compressed data frame for transmission over the wireless access interface; receiving a second data frame comprising a second protocol header associated with the MAC frame format; and determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context prior to transmission of the second data frame over the wireless access interface.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a communications device, infrastructure equipment and method for compressing and decompressing data in a wireless communications network.

[0002] This disclosure claims Paris Convention priority from European Patent Application No. 20175569.1, the contents of which are incorporated herein in their entirety by reference. BACKGROUND

[0003] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Aspects described in this section that would be apparent to one of ordinary skill in the art, especially in the presence of the related art, however, are not to be considered as prior art to the present invention.

[0004] Third and fourth generation mobile communication systems, such as those based on the 3GPP-defined UMTS and Long Term Evolution (LTE) architecture, are able to support more sophisticated services than simple voice and messaging services offered by previous generations of mobile telecommunication systems. For example, with the improved radio interface and enhanced data rates provided by LTE systems, a user is able to enjoy high data rate applications such as mobile video streaming and mobile video conferencing that would previously only have been available via a fixed line connection. The demand to deploy such networks is therefore strong and the coverage area of these networks, i.e. the geographic locations where access to the networks is possible, can be expected to increase ever more rapidly.

[0005] Future wireless communications networks are expected to regularly and efficiently support communications with a wider range of devices associated with a wider range of data traffic profiles and types than current systems are optimised to support. For example, it is expected that future wireless communications networks will efficiently support communications with devices including reduced complexity devices, machine type communication (MTC) devices, high-resolution video displays, virtual reality headsets and so on. Some of these different types of devices can be deployed in very large numbers, for example low complexity devices for supporting the "Internet of Things", and can typically be associated with the transmission of relatively small amounts of data with relatively high latency tolerance.

[0006] In view of this, it is desirable that such wireless communications networks, for example can be referred to as 5G or New Radio (NR) system / New Radio Access Technology (RAT) systems [1], and future iterations / releases of existing systems, efficiently support connectivity for a wide range of devices associated with different applications and different characteristic data traffic profiles.

[0007] One example of such new type of service is referred to as Ultra-Reliable Low Latency Communication (URLLC) service, which as the name implies, requires data units or packets to be communicated with high reliability and low communication latency. Thus, URLLC type services represent a challenging example for both LTE type communication systems and 5G / NR communication systems.

[0008] The need to provide low latency, high reliability data transmission to efficiently utilize wireless communication resources presents new challenges to be addressed for efficient handling of communications in wireless telecommunication systems. SUMMARY

[0009] The present disclosure can help to address or mitigate at least some of the problems described above.

[0010] Various aspects and features of the present disclosure are defined in the appended claims.

[0011] It is to be understood that both the foregoing general description and the following detailed description are exemplary, but are not restrictive, of the technology. The described embodiments will be best understood by reference to the detailed description, taken in conjunction with the accompanying drawings, in which: BRIEF DESCRIPTION OF DRAWINGS

[0012] A more complete understanding of the present disclosure and the many attendant advantages thereof will be readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings, wherein like reference numerals are used throughout the several views to represent the same or corresponding parts, and wherein:

[0013] Figure 1 Aspects of an LTE type wireless telecommunication system are schematically illustrated, which system can be configured to operate in accordance with certain embodiments of the present disclosure;

[0014] Figure 2 Aspects of a new Radio Access Technology (RAT) wireless telecommunication system are schematically illustrated, which system can be configured to operate in accordance with certain embodiments of the present disclosure;

[0015] Figure 3 is a schematic block diagram of an example infrastructure equipment and a communications device configured in accordance with example embodiments;

[0016] Figure 4 shows the IEEE 802.3 Media Access Control (MAC) frame format, in accordance with the IEEE 802.1Q (2014) specification;

[0017] Figure 5 is a combined message sequence chart and processing flow diagram showing the use of Ethernet Header Compression (EHC) in accordance with an existing proposal;

[0018] Figure 6 A part of an EHC feedback packet according to the current proposal is shown;

[0019] Figure 7 is a combined message sequence chart and processing flow chart illustrating the use of EHC according to embodiments of the present technology;

[0020] Figure 8 is a combined message sequence chart and processing flow chart illustrating the use of EHC according to embodiments of the present technology; and

[0021] Figure 9 is a flow chart of a process that can be performed by a compressor according to embodiments of the present technology. DETAILED DESCRIPTION

[0022] Long Term Evolution Advanced Radio Access Technology (4G)

[0023] Figure 1 The schematic provided illustrates some basic functionalities of a mobile communication network / system 100 that operates generally according to LTE principles, but it can also support other radio access technologies, and it can be adapted to implement embodiments of the present disclosure as described herein. Figure 1 Various elements of the network and certain aspects of their respective modes of operation are well known and defined in the relevant standards governed by the 3GPP (RTM) body, and also described in many books on the subject, for example Holma H. and Toskala A [2]. It will be appreciated that operational aspects of the telecommunication network discussed herein that are not specifically described (for example with respect to specific communication protocols and physical channels used to communicate between different elements) can be implemented according to any known technology, for example according to the relevant standards and known modifications and additions to the relevant standards.

[0024] The network 100 comprises a plurality of base stations 101 connected to a core network part 102. Each base station provides a coverage area 103 (e.g. a cell) within which data can be transmitted to and from communication devices 104. Data is transmitted from base stations 101 to communication devices 104 within their respective coverage areas 103 via a radio downlink. Data is transmitted from communication devices 104 to the base stations 101 via a radio uplink. The core network part 102 routes data to and from communication devices 104 via the respective base stations 101 and provides functions such as authentication, mobility management, charging and so on. Communication devices can also be known as mobile stations, user equipment (UE), user terminals, mobile radios, terminal devices and so forth. Base stations can also be known as transceiver stations / nodeBs / e-nodeBs / g-nodeBs (gNB) and so forth as examples of network infrastructure equipment / network access nodes. In this regard, different terminology is often associated with different generations of wireless telecommunications systems for elements providing broadly comparable functionality. However, example implementations of the disclosure can equally be implemented in different generations of wireless telecommunications systems such as 5G or New Radio as explained below and certain terminology can be used for simplicity regardless of the underlying network architecture. That is, use of particular terminology in relation to certain example implementations is not intended to indicate that those implementations are restricted to a certain generation of network with which that particular terminology might be most closely associated.

[0025] New Radio Access Technology (5G)

[0026] Figure 2 is a schematic diagram showing a network architecture of a New RAT wireless communication network / system 200 based on a previously proposed approach which can also be adapted to provide functionality in accordance with example implementations of the disclosure described herein. Figure 2The novel RAT network 200, as shown in the diagram, includes a first communication cell 201 and a second communication cell 202. Each communication cell 201, 202 includes control nodes (centralized units) 221, 222 that communicate with the core network component 210 via corresponding wired or wireless links 251, 252. The corresponding control nodes 221, 222 also communicate with multiple distributed units (radio access nodes / remote transmit and receive points (TRPs)) 211, 212 within their respective cells. Again, these communications can be conducted via corresponding wired or wireless links. Distributed units 211, 212 are responsible for providing radio access interfaces for communication devices connected to the network. Each distributed unit 211, 212 has a coverage area (radio access coverage area) 241, 242, wherein the sum of the coverage areas of the distributed units under the control of the control nodes collectively defines the coverage of the corresponding communication cell 201, 202. Each distributed unit 211, 212 includes transceiver circuitry for transmitting and receiving wireless signals and processor circuitry configured to control the respective distributed unit 211, 212.

[0027] In terms of the broadest sense of top-level functions, Figure 2 The core network component 210 of the novel RAT communication network shown can be broadly considered to correspond to... Figure 1 The core network 102 shown, along with the corresponding control nodes 221 and 222 and their associated distributed units / TRPs 211 and 212, can be broadly considered as providing [services / equipment / etc.]. Figure 1 The functions corresponding to base station 101. The term network infrastructure equipment / access node can be used to cover these elements of wireless communication systems and more conventional base station type elements. Depending on the current application, the responsibility for scheduling transmissions on the radio interfaces between the various distributed units and communication devices may lie with the control node / centralized unit and / or distributed unit / TRP.

[0028] exist Figure 2 The diagram illustrates a communication device or UE 260 within the coverage area of ​​the first communication cell 201. Therefore, the communication device 260 can exchange signaling with the first control node 221 in the first communication cell via one of the distributed units 211 associated with the first communication cell 201. In some cases, communication for a given communication device is routed through only one of the distributed units; however, it should be understood that in some other implementations, communication associated with a given communication device can be routed through more than one distributed unit, such as in soft handover scenarios and other scenarios.

[0029] exist Figure 2In the example of Figure 2, for simplicity, two communication cells 201, 202 and one communication device 260 are shown, but it will of course be appreciated that in practice the system can comprise a larger number of communication cells serving a larger number of communication devices (each communication cell being supported by a respective control node and a plurality of distributed units).

[0030] It will also be appreciated that, Figure 2 the proposed architecture for a new RAT communication system is merely one example in which approaches in accordance with the principles described herein can be employed, and that the functionality disclosed herein can also be applied to wireless communication systems having different architectures.

[0031] Accordingly, example implementations of the disclosure discussed herein can be implemented in wireless telecommunication systems / networks in accordance with a variety of different architectures, such as the example architecture shown in Figure 1 and Figure 2 . Accordingly, it will be appreciated that the specific wireless communication architecture in any given implementation is not of primary significance to the principles described herein. In this regard, certain implementations of the disclosure can be generally described in the context of communications between network infrastructure equipment / access nodes and communication devices, with the specific nature of the network infrastructure equipment / access nodes and communication devices depending on the network infrastructure being implemented. For example, in some scenarios the network infrastructure equipment / access nodes can comprise base stations, such as the LTE-type base station 101 shown in Figure 1 , which are adapted to provide functionality in accordance with the principles described herein, and in other examples the network infrastructure equipment / access nodes can comprise control units / control nodes 221, 222 and / or TRPs 211, 212 of the type shown in Figure 2 , which are adapted to provide functionality in accordance with the principles described herein.

[0032] A more detailed illustration of a communication device 270 and an example network infrastructure equipment 272, which can be considered to be a combination of a gNB 101 or control node 221 and TRP 211, is presented in Figure 3 . As shown in Figure 3 , the communication device 270 is shown transmitting uplink data to the infrastructure equipment 272 via grant-free resources of the wireless access interface, as generally indicated by arrow 274. The UE 270 is shown receiving downlink data transmitted by the infrastructure equipment 272 via resources of the wireless access interface, as generally indicated by arrow 288. As with Figure 1 and Figure 2 , the infrastructure equipment 272 is connected to a core network 276 (which can correspond to the core network 102 of Figure 1 or Figure 2 .to the core network 210). The infrastructure equipment 272 can also be connected to other similar infrastructure equipment (not shown in Figure 3) by means of an inter-infrastructure equipment interface. Figure 3

[0033] The infrastructure equipment 272 comprises a receiver 282 connected to an antenna 284 and a transmitter 286 also connected to the antenna 284. Correspondingly, the communications device 270 comprises a controller 290 connected to a receiver 292 which receives signals from an antenna 294 and a transmitter 296 also connected to the antenna 294.

[0034] The controller 280 is configured to control the infrastructure equipment 272 and can comprise processor circuitry which in turn can comprise various sub-units / sub-circuits for providing functionality as explained further herein. These sub-units can be implemented as discrete hardware elements or as appropriately configured functions of the processor circuitry. The controller 280 can thus comprise circuitry which is suitably configured / programmed to provide the desired functionality using conventional programming / configuring techniques for devices in wireless telecommunications systems. The transmitter 286 and the receiver 282 can comprise signal processing and radio frequency filters, amplifiers and circuitry in accordance with conventional arrangements. For ease of representation, the transmitter 286, the receiver 282 and the controller 280 are shown schematically as separate elements in Figure 3. However, it will be appreciated that the functionality of these elements can be provided in various different ways, such as using one or more appropriately programmed programmable computer(s), or one or more appropriately configured application-specific integrated circuit(s) / circuitry / chip(s) / chipset(s). As will be appreciated, the infrastructure equipment 272 will in general comprise various other elements associated with its operational functionality. Figure 3

[0035] Correspondingly, the controller 290 of the communications device 270 is configured to control the transmitter 296 and the receiver 292 and can comprise processor circuitry which in turn can comprise various sub-units / sub-circuits for providing functionality as explained further herein. These sub-units can be implemented as discrete hardware elements or as appropriately configured functions of the processor circuitry. The controller 290 can thus comprise circuitry which is suitably configured / programmed to provide the desired functionality using conventional programming / configuring techniques for devices in wireless telecommunications systems. Likewise, the transmitter 296 and the receiver 292 can comprise signal processing and radio frequency filters, amplifiers and circuitry in accordance with conventional arrangements. For ease of representation, the transmitter 296, the receiver 292 and the controller 290 are shown schematically as separate elements in Figure 3. However, it will be appreciated that the functionality of these elements can be provided in various different ways, such as using one or more appropriately programmed programmable computer(s), or one or more appropriately configured application-specific integrated circuit(s) / circuitry / chip(s) / chipset(s). As will be appreciated, the communications device 270 will in general comprise various other elements associated with its operational functionality. Figure 3 ​​In the drawings, like reference numerals refer to like elements throughout. It will be understood that elements having the same or similar reference numerals, referenced across different figures, can include the same, or similar, parts, or functions, unless context dictates otherwise. Furthermore, in the drawings, the relative sizes of elements can be shown exaggerated or smaller than actual to illustrate certain features clearly. In the description below, numerous specific details are discussed to provide a thorough understanding of various embodiments. However, embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail since it would be Figure 3 understood by persons of ordinary skill in the art.

[0036] Conventionally, a wireless communication network interfaces with external networks at the Internet Protocol (IP) layer. That is, a gateway of the wireless communication network receives IP packets in which an intended recipient communication device is identified as one or more destination address fields, such as an IP destination address and / or port number. Similarly, outbound data is formed as IP packets in which a source communication device is identified as a source IP address and / or source port number. (Note that this can be the case even if techniques such as network address translation are used, which modify these addresses by a gateway or other entity such that the address fields on inbound and / or outbound packets are modified at the logical boundary of the wireless communication network).

[0037] It will be appreciated that lower layer protocols can be used both within the wireless communication network and externally thereto, for example on links terminating at the gateway. However, the headers associated with these protocols can typically be discarded before encapsulated IP packets are forwarded.

[0038] Conventionally, when transmitting Internet Protocol (IP) packets over a wireless access interface, a wireless communication network compresses Internet Protocol (IP) headers by exploiting the redundancy between the headers of successive IP packets. To ensure that an IP header compressor at the transmitter and an IP header decompressor at the receiver remain synchronised, an uncompressed full header is transmitted periodically. Thus, the receiver has the possibility to reconstruct the original (uncompressed) IP header before forwarding the IP packet or passing it to higher layers in the protocol stack. Header compression can be lossless and can result in a significant increase in the efficiency of use of communication resources on the wireless access interface.

[0039] Recently, there has been some interest in allowing wireless communication network interfaces at lower protocol layers. In particular, a gateway of a wireless communication network can receive data frames formatted according to an Institute of Electrical and Electronics Engineers (IEEE) 802.3 frame format or according to an Ethernet frame format, and can transmit such frames within the wireless communication network so that a complete Ethernet frame received at the gateway is available to an end recipient. Similarly, a communication device can construct frames according to such specifications for transmission outside the wireless communication network. Ethernet and IEEE 802.3 can be examples of media access control (MAC) frame formats for data transmission within a local area network (LAN).

[0040] It will be appreciated that the frame format of IEEE 802.3 and the frame format of Ethernet are very similar, the extent of their differences can be immaterial to the presently disclosed technology, and thus the terms can be used interchangeably in the present disclosure. Techniques for header compression at one layer can be combined with header compression at another layer. For example, an Ethernet frame contained within an Internet Protocol (IP) packet can be subject to header compression of both the Ethernet frame header and the IP header. The IP header can be compressed according to conventional reliable header compression (ROHC) techniques.

[0041] Figure 4 An IEEE 802.3 MAC frame format according to the IEEE 802.31Q (2014) specification is shown.

[0042] The IEEE 802.3 MAC frame 1000 includes a MAC header 1002, MAC client data and padding 1004, and a frame check sequence (FCS) 1006. The MAC header 1002 includes a preamble 1010 of length 7 octets and a start frame delimiter (SFD) 1012 of 1 octet. This is followed by a destination address field 1014 and a source address field 1016, each of 6 octets.

[0043] The MAC header 1002 also includes a length / type field 1018 and a tag control information field 1020, each of 2 octets. The length / type field 1018 and the tag control information field 1020 can be referred to collectively as a Q-tag prefix.

[0044] The MAC header 1002 also includes a MAC client length / type field 1022 (2 octets), which can include a predetermined value to indicate the presence of the tag control information field 1020.

[0045] The tag control information field 1020 can include a priority indication field 1030 (3 bits), a drop eligible indicator (DEI) bit 1032, and a virtual local area network (VLAN) identifier field 1034 (12 bits).

[0046] In some embodiments, for example where the IEEE 802.1Q (2014) specification does not apply, the MAC header 1002 can not contain the tag control information field 1020.

[0047] Figure 5 is a combined message sequence chart and process flow chart illustrating the use of EHC in accordance with the existing proposal.

[0048] Figure 5 Examples of relate to downlink frames (i.e. frames transmitted from the infrastructure equipment 272 to the communications device 270), however, it will be appreciated that the disclosure is not limited to such directions and can be applied to uplink or peer-to-peer (e.g. device-to-device) transmissions.

[0049] At the start of the procedure shown, the infrastructure equipment 272 and the communications device 270 can have completed a connection establishment procedure, which can broadly be in accordance with conventional techniques, for example by radio resource control (RRC) reconfiguration. Figure 5 As part of or otherwise the connection establishment procedure, the communications device 270 can be configured (e.g. by RRC configuration) such that EHC can be applied for a sequence of downlink frames. The sequence of downlink frames can be defined by one or more of a common destination address, an associated bearer (such as a data bearer or a dedicated radio bearer, DRB) and an associated protocol data unit (PDU) session. For example, the sequence can be characterised by a DRB in conjunction with a destination address. The sequence of downlink frames can be associated with an Ethernet type PDU session.

[0050] At step S502, a first downlink frame 550 for transmission to the communications device 270 is transmitted by the core network 276 and received at the infrastructure equipment 272. The first downlink frame 550 comprises an Ethernet header. It will be appreciated that the first downlink frame 550 (and other downlink frames referred to herein) can further comprise a header in accordance with a packet or frame format associated with the respective protocol used in the transmission of the frame. For example, the first downlink frame 550 can be encapsulated within one or more general packet radio service (GPRS) tunneling protocol (GTP) packets when transmitted from the core network 276 to the infrastructure equipment 272, each GTP packet comprising a GTP header.

[0051]

[0052] ​Furthermore, frames referred to herein can be segmented and reassembled and / or retransmitted, as well as being subject to other processing in accordance with protocols and techniques associated with the respective interfaces through which they are transmitted. These protocols can include medium access control (MAC), radio link control (RLC) and protocol data convergence protocol (PDCP) protocols. Details of these are omitted from the present specification.

[0053] Because EHC relies on a compression context based on a previously transmitted frame, it is not possible to use EHC to compress the Ethernet header of the first downlink frame 550. Accordingly, at step S504, the first downlink frame 550 is transmitted to the communications device 270 via the wireless access interface 288.

[0054] It will be appreciated that additional steps (encoding, modulation, forward error correction, etc.) can be performed as part of the transmission of a downlink frame (e.g. the first downlink frame 550) via the wireless access interface. For example, in some embodiments, a packet data convergence protocol (PDCP) protocol data unit (PDU) can be formed which includes the respective downlink frame. Encryption and / or integrity protection functions can be applied to the respective downlink frame.

[0055] Details of these steps are omitted for the sake of brevity, and can be in accordance with any appropriate techniques. In some embodiments of the present techniques, the transmission via the wireless access interface can be in accordance with known techniques for the transmission of URLLC data via a 5G (NR) wireless access interface.

[0056] At step S506, the infrastructure equipment 272 establishes an EHC context for compressing subsequent frames including Ethernet headers destined for the communications device 270. The EHC context can be associated with a context ID. The context can be established based on one or more of the header fields of the first downlink frame 550.

[0057] At step S508, the communications device 270 establishes a corresponding EHC context for decompression of subsequent frames including Ethernet headers destined for the communications device 270 and transmitted by the infrastructure equipment 272. The context can be associated with a context ID. The context can be established based on one or more of the header fields of the first downlink frame 550. The first downlink frame 550 can be transmitted with an indication of the context ID, or modified to include an indication of the context ID. Accordingly, the communications device 270 can determine the context ID based on the received first downlink frame 550.

[0058] The received first downlink frame 550 can be transmitted to or towards its destination (i.e. the communications device 270) via the wireless access interface 288. Figure 5The destination can be another logical process running on the communications device 270, or can be another entity to which the communications device 270 is directly or indirectly connected.

[0059] At step S510, the communications device 270 transmits an EHC acknowledgement (ACK) 552 to the infrastructure equipment 272. The EHC ACK 552 can indicate to the infrastructure equipment 272 that the communications device 270 has established its EHC context and is ready to receive a subsequent downlink frame, with one or more fields of the Ethernet header having been compressed using EHC.

[0060] The EHC ACK 552 can comprise an indication of the context ID.

[0061] At step S512, a second downlink frame 554 for transmission to the communications device 270 is transmitted by the core network 276, and received at the infrastructure equipment 272. The second downlink frame 554 comprises an Ethernet header.

[0062] Because both the infrastructure equipment 272 and the communications device 270 have established corresponding EHC contexts, at step S514 the infrastructure equipment 272 applies EHC to the second downlink frame 554, based on the context created at step S506, to create a modified version of the second downlink frame. The modified version of the second downlink frame can comprise an indication of the context ID. As part of step S514, the context can be updated.

[0063] At step S516, the modified version of the second downlink frame 556, with one or more fields of the Ethernet header compressed, is transmitted to the communications device 270 via the wireless access interface.

[0064] At step S518, based on the context established at step S508, the communications device 270 applies decompression to the compressed Ethernet header fields to reconstruct the original second downlink frame 556. As part of this decompression, the communications device 270 can remove the indication of the context ID. As part of step S518, the communications device 270 can update its context.

[0065] For successive downlink frames, steps S512, S514, S516 and S518 can be repeated, (with each frame at the infrastructure equipment 272 being EHC based on the context), transmitted, modified, via the wireless access interface to the communications device 270, and reconstructed with decompression of the Ethernet header.

[0066] For each downlink frame, the context at the infrastructure equipment and the communication equipment can be updated so that the compression / decompression of the frame depends on the context, which in turn can depend on the contents of the Ethernet header of a previously transmitted frame.

[0067] However, it can happen that a particular frame is not successfully reconstructed at the communication equipment 270. This can be due to any reason. For example, an error introduced when receiving the frame over the wireless access interface can cause the frame (received in the header decompression process) to be in error. Alternatively, the frame can not be received at all in the header decompression process - this can be because an error detected elsewhere in the protocol stack causes the frame to be discarded. The attempt to reconstruct can fail because the context at the compressor / decompressor has been corrupted.

[0068] In the example of Figure 5 At step S520, a third downlink frame 558 is received at the infrastructure equipment 272, and at step S522 header compression is applied to form a modified frame 560. At step S524, the modified third downlink frame 560 is transmitted to the communication equipment 270. However, decompression of the compressed Ethernet header within the modified third downlink frame 560 is not successfully completed. In some examples, decompression is not attempted at all. In other examples, decompression is attempted at step S526, but is not successful. Figure 5 In the example of At step S520, a third downlink frame 558 is received at the infrastructure equipment 272, and at step S522 header compression is applied to form a modified frame 560. At step S524, the modified third downlink frame 560 is transmitted to the communication equipment 270. However, decompression of the compressed Ethernet header within the modified third downlink frame 560 is not successfully completed. In some examples, decompression is not attempted at all. In other examples, decompression is attempted at step S526, but is not successful.

[0069] It is further apparent that when the compression context in the compression and decompression process relies on the previously compressed / decompressed header, a failure to decompress one frame can cause subsequent failures or errors in decompressing subsequent frames.

[0070] In the example of Figure 5 At step S522, the infrastructure equipment 272 updates the EHC context. However, after step S526, as part of step S526, or without step S526, the communication equipment 270 can not update its context at all, or can update its context incorrectly.

[0071] Thus, the compression context at the infrastructure equipment 272 and the decompression context at the communication equipment 270 are no longer synchronised.

[0072] In the example of Figure 5In the example, this can result in a failure to decompress the fourth downlink data frame 562 received by the infrastructure equipment 272 in step S528. In step S530, the fourth downlink data frame is compressed according to the context updated in step S522. In step S532, the modified (i.e. with compressed Ethernet header) frame 564 is transmitted to the communication device 270.

[0073] However, in step S534, the communication device 270 attempts to decompress the modified fourth downlink data frame 564 based on a context that has not been updated or has been incorrectly updated (since after the transmission of the third modified downlink data frame 560). As a result, the decompression can fail or result in an erroneous reconstructed frame.

[0074] For services such as Industrial Internet of Things (IIoT) services, high reliability of data transmission is required, and it is proposed (see [6]) that the 3GPP NR system can support compression of Ethernet frame headers by Ethernet Header Compression (EHC) to improve the efficient use of communication resources on the wireless access interface.

[0075] In the case that the decompressor receives a frame with a compressed header associated with an unknown context (i.e. with a context ID, CID, that it does not recognise), it is proposed that the decompressor discards the frame, informs the compressor with a negative acknowledgement, or performs a radio link failure procedure [5]. It is further proposed that when the decompressor receives a compressed packet with an unknown CID, the compressor should be informed so that the compressor can switch to full header transmission.

[0076] In [3], it has been proposed that the EHC solution should allow transmission of full (uncompressed) headers between transmissions of frames with compressed headers.

[0077] In [4], it has been proposed to provide Ethernet header compression feedback in the packet data convergence protocol (PDCP) header, and that this Ethernet header compression feedback is configurable by the network. The feedback is used to indicate the state of synchronisation between the compressor and the decompressor.

[0078] In [6], it has been proposed to define an EHC feedback packet. The operation of EHC is proposed to be found in the appendix A of [6].

[0079] Figure 6 A portion of an EHC feedback packet 1600 according to the existing proposal (see [6]) is shown. The feedback packet comprises context ID indications (1602a, 1602b) and reserved bits 1604. The context ID indications can comprise 7 bits (in which case octet 2 can be omitted) or 15 bits.

[0080] There remains a need to provide improved techniques and apparatus for reliable transmission of data, while efficiently utilising radio resources, in particular for transmission of Ethernet frames.

[0081] Accordingly, there is provided a method of processing data frames for transmission over a wireless access interface of a wireless communication system, the method comprising receiving a first data frame comprising a first protocol header associated with a Media Access Control (MAC) frame format for data transmission within a Local Area Network (LAN), applying header compression to the first data frame according to a header compression context by compressing one or more protocol header fields of the first protocol header to form a first compressed data frame for transmission over the wireless access interface, receiving a second data frame comprising a second protocol header associated with the MAC frame format, and determining that no fields of the second protocol header will be compressed according to the header compression context prior to transmission of the second data frame over the wireless access interface.

[0082] Accordingly, embodiments of the present technology can provide reliable transmission of subsequent frames after a previously transmitted frame, which had compression applied to the Ethernet header prior to transmission, fails to decompress correctly. Certain embodiments of the present technology can avoid the need for explicit per-frame feedback from a decompressor.

[0083] In some embodiments, the compressor establishes an EHC context for compressing some or all of the fields within the Ethernet header of frames associated with a data flow, and performs EHC in accordance with the context for one or more such frames. The compressor then determines that EHC is not to be applied in accordance with the existing context for one or more subsequent frames associated with the data flow, and transmits the one or more subsequent frames without applying the EHC accordingly.

[0084] In some embodiments, the compressor additionally or alternatively determines to establish a new compression context, and to apply header compression in accordance with the new context for one or more subsequent frames that would otherwise be associated with the previously established context.

[0085] Frames can be associated with one another (and thus, traditionally, with a single context) based on one or more of their destination, associated data bearer and associated Protocol Data Unit (PDU) session. Unless explicitly stated otherwise, sequences of frames in a given direction described herein are associated with one another.

[0086] In some embodiments, the compressor additionally retransmits one or more frames for which EHC was previously applied.

[0087] Retransmitted frames can be EHC compressed. In some embodiments, retransmitted frames are compressed according to a previous context. In some embodiments, retransmitted frames are compressed according to a newly established context. Where this results in the same frame being transmitted and successfully received (after any decompression) more than once, de-duplication can be performed. De-duplication can be performed by a higher layer protocol entity.

[0088] In some embodiments, a determination is made not to apply EHC to one or more subsequent frames based on feedback received from a corresponding peer decompressor entity.

[0089] In some embodiments, feedback from a decompressor is explicit and can include a negative acknowledgement (NACK) indication that one or more frames of a data stream could not be properly decompressed and / or that a context identifier associated with a compressed packet does not correspond to a valid compression context. According to some embodiments of the present technology, explicit NACK feedback is included in an EHC feedback packet. For example, in some embodiments, a reserved bit 1604 of the EHC feedback packet 1600 is used to indicate a NACK. When the reserved bit 1604 is set to a first value (e.g., “0”), no NACK feedback is indicated. When the reserved bit 1604 is set to a second value (e.g., “1”), NACK feedback is indicated.

[0090] In some embodiments, NACK feedback can not be associated with a particular context ID, e.g., in the case that a context identifier associated with a compressed packet does not correspond to a valid compression context.

[0091] In some embodiments, in response to receiving such NACK feedback that is not associated with a particular context ID, an entity performing compressor functionality (e.g., infrastructure equipment 272) can consider the NACK feedback to apply to each EHC context used to compress frames that are destined for the entity performing compressor functionality (e.g., a communication device 270). Thus, for example, when multiple EHC contexts are being used in parallel for different sequences of data frames that are destined for (or transmitted to) the same receiving entity (e.g., a communication device or infrastructure equipment), in response to receiving such NACK feedback, one or more data frames of each sequence can be transmitted without applying the corresponding EHC context. These frames can be transmitted in uncompressed fashion and / or can be used to establish a new respective EHC context for the respective sequence of frames.

[0092] In some embodiments, a decompressor only transmits positive feedback indicating that the decompressor has properly decompressed a header of one or more frames. In some such embodiments, a compressor determines not to apply EHC in response to determining that expected positive feedback has not been received from the decompressor.

[0093] In some such implementations, the feedback identifies only the context identifier, and not a particular packet. In some implementations, positive feedback is transmitted not only during the initial context establishment phase, but also in response to successful decompression of each header as the frames are successfully decompressed.

[0094] In some implementations in which the decompressor generates a feedback packet for each EHC packet received and successfully decompressed, the compressor can implement a sliding window mechanism, whereby if EHC is applied to a first number of packets and the first number of packets are transmitted within a transmission window, the compressor determines not to apply EHC in response to determining that the EHC feedback packets received in a corresponding reception window are less than a second number, which is no higher than the first number. The difference between the first number and the second number can be zero.

[0095] The additional steps taken by the compressor (e.g., establishing a new context) can depend on the amount of EHC feedback received during the reception window.

[0096] The second number (or the difference between the first number and the second number) can be configured by the network or otherwise preconfigured to the compressor.

[0097] In some implementations, the positive feedback generated by the decompressor (e.g., by transmitting a feedback packet) does not indicate the number of frames that have been successfully decompressed.

[0098] In some implementations, however, the compressor determines not to apply EHC based on the amount of such feedback received.

[0099] In some implementations, a timer is defined, which is started upon transmission or compression of a particular data frame. The compressor determines not to apply EHC using the existing context in response to determining that no positive feedback has been received from the peer decompressor before expiration of the timer.

[0100] In some implementations, the determination not to apply EHC is made autonomously, without regard to any explicit feedback received from the peer decompressor, and / or in the absence of explicit feedback received from the peer decompressor.

[0101] In some implementations, a new context can be created after a threshold number of frames compressed according to the existing context. The threshold can be preconfigured, or determined dynamically. For example, in some implementations, after 100 frames have been compressed according to a context, a new context is established, and subsequent frames that would have been processed according to the original context (e.g., because they are associated with a particular data flow) are processed according to the new context. This process can be repeated.

[0102] In some embodiments, the condition that the compressor determines not to apply EHC using the existing context is specified in a suitable standards specification. In some embodiments, additionally or alternatively, the one or more conditions can be pre-configured at the compressor, or indicated using control signalling from a controlling entity.

[0103] In some embodiments, the condition is associated with one or more parameters. The one or more parameters can be specified in a suitable standards specification, pre-configured at the compressor, and / or indicated using control signalling from a controlling entity.

[0104] In some embodiments, the entity performing the function of the compressor can also perform the function of the decompressor. That is, for example, the infrastructure equipment 272 can perform compression using EHC on frames to be transmitted on the downlink of the wireless access interface to the communication devices, and can also perform decompression using EHC on frames transmitted by the communication devices on the uplink of the wireless access interface. Similarly, for example, the communication device 270 can perform compression using EHC on frames to be transmitted on the uplink of the wireless access interface to the infrastructure equipment, and can also perform decompression using EHC on frames transmitted by the infrastructure equipment on the downlink of the wireless access interface. In the case where the same entity performs the functions of the compressor and the decompressor, these entities can operate in a corresponding manner, or can operate using different techniques. For example, an entity providing the function of the decompressor can provide positive feedback regarding successful decompression of each header, whereas the compressor function provided by the same entity can operate without regard to any positive feedback, or can operate according to a different procedure or option without regard to any positive feedback.

[0105] For example, such an entity can provide positive feedback in response to successful decompression of each frame, and can determine not to apply EHC compression using the existing context based on an expectation that the peer entity also provides positive feedback in response to successful decompression of each frame.

[0106] Alternatively, for example, an entity can provide positive feedback in response to successful decompression of each frame, but can determine not to apply EHC compression using the existing context regardless of (and therefore without requiring or expecting) any feedback generated by the peer entity.

[0107] Figure 7 is a combined message sequence chart and processing flow diagram illustrating the use of EHC according to embodiments of the present technology.

[0108] Figure 7 Many of the features and steps of Figure 5 correspond to similarly numbered features and steps of

[0109] In particular, in the example of Figure 7 Steps S502-S520 can occur as in the example of Figure 5 Steps S502-S520 can occur as in the example of

[0110] In the example of Figure 7 The decompressor entity (within the communication device 270) provides positive feedback regarding each frame in which the header is successfully decompressed. Thus, in addition to the positive feedback 552 transmitted at step S510, the decompressor also generates positive feedback (ACK) 602 transmitted at step S620. In response to the successful decompression of the header of the modified version of the second downlink frame 556, the ACK 602 is transmitted at step S518.

[0111] Steps S520, S622, S624 and S626 can then occur, corresponding to steps S520, S522, S524 and S526 as in the example of Figure 5 above.

[0112] In some embodiments, step S622 occurs in response to receiving the ACK 602.

[0113] In response to the failure of decompression at step S626 (or as a result of not having any decompression attempt), the compressor entity of the communication device 270 does not generate an ACK to indicate successful decompression of the modified third downlink frame 560.

[0114] In step S628, the infrastructure apparatus 272 receives a fourth downlink data frame 562 from the core network 276.

[0115] In response to receiving the fourth downlink data frame 562 and in response to determining that no positive feedback is received from the compressor indicating successful decompression of the modified third downlink frame 560, the compressor determines not to apply EHC (using the existing context) to the fourth downlink data frame 562. Thus, in step S630, the fourth downlink data frame 562 is transmitted without applying EHC.

[0116] In steps S632 and S634, the compressor and the decompressor establish a new EHC context for the data stream. The new context can be based on the fourth downlink data frame 562. The context ID of the new EHC context can be transmitted with the fourth downlink data frame 562.

[0117] In step S636, the decompressor generates a positive acknowledgement (ACK) 606 to indicate that the new context is established. The ACK 606 is transmitted to the compressor.

[0118] Subsequently, the compressor continues to apply EHC compression based on the new context, as long as it receives positive acknowledgements indicating that the decompressor successfully decompressed each compressed header.

[0119] Figure 8 is a combined message sequence chart and processing flow chart illustrating the use of EHC according to embodiments of the present technology.

[0120] In Figure 8 examples, the compressor generates separate positive feedback indications for each successfully decompressed header, or generates feedback indicating how many headers have been successfully decompressed. However, in some embodiments, the feedback does not indicate which header(s) (and accordingly, frame(s)) the feedback relates to.

[0121] As Figure 8 illustrates, in some embodiments, the compressor maintains a sliding transmission window and a sliding reception window. The sliding reception window can be offset (e.g., delayed) in time relative to the transmission window. The duration of the reception window can exceed the duration of the transmission window.

[0122] If the number of headers compressed and / or transmitted within the transmission window exceeds a predetermined number compared to the number of headers indicated by the feedback to have been successfully decompressed, the compressor determines to stop (at least temporarily) using EHC according to the current context of the frames to be transmitted.

[0123] In some embodiments, the feedback indication indicates a data stream and / or a context ID.

[0124] Steps S502, S504, and S506 can occur as in the example of Figure 5 and as described above.

[0125] In Figure 8 examples, a transmission window 702 and a corresponding reception window 704 are illustrated. The transmission window 702 and the reception window 704 are “corresponding” in the sense that the number of headers for which EHC compression is applied in the transmission window 702 is compared to the number of headers indicated as correctly decompressed as indicated by acknowledgements received during the reception window 704.

[0126] In Figure 8 examples, each acknowledgement 708 generated by the decompressor at the communication device 270 indicates that one header has been correctly decompressed. The acknowledgement 708 can indicate the context ID used for decompression. Each acknowledgement 708 can not identify which frame(s) were successfully decompressed, triggering the respective acknowledgement.

[0127] As Figure 8 illustrates, within the reception window 704, four acknowledgements 708 are received, indicating that four headers were successfully decompressed.

[0128] During the respective transmission window 702, five headers are compressed by the compressor at the infrastructure equipment 272.

[0129] Thus, the compressor determines that the number of headers compressed during the transmission window 702 is more than the number of headers indicated as successfully decompressed within the receive window 704.

[0130] In the example of Figure 7, the threshold of this difference is zero, at which point header compression using the current context is not used, i.e. any difference between the number of headers compressed during the transmission window 702 and the number of headers indicated as successfully decompressed within the receive window 704 results in stopping header compression. Figure 8 In some embodiments, the threshold is zero. In other embodiments, the threshold is a different value.

[0131] At step S710, the compressor determines that EHC compression using the current context is to be stopped. In the example of Figure 7, at least one subsequent frame 710 is transmitted without any EHC compression being applied.

[0132] Figure 8 In the example of Figure 7, at least one subsequent frame 710 is transmitted without any EHC compression being applied.

[0133] In some embodiments, a new context is established after step S710.

[0134] In some embodiments, the existing context is re-established based on the transmission of one or more frames for which EHC header compression is not applied.

[0135] In some embodiments, one or more of the frames transmitted during the transmission window 702 are retransmitted.

[0136] Figure 9 is a flowchart of a process that can be performed by a compressor in accordance with embodiments of the technology. The compressor function can be implemented by an infrastructure equipment (for data transmitted on the downlink of a wireless access interface) or by a communications device (for data transmitted on the uplink of a wireless access interface, or via peer-to-peer communications). However, the present disclosure is not limited to this, and Figure 9 The process of Figure 8 can be performed by any suitable entity.

[0137] Figure 9 The process of Figure 8 can be implemented by a processor or controller in accordance with a program stored on a computer readable medium. The processor or controller can operate in conjunction with transmitter and receiver circuitry for transmitting and receiving signals on a wireless access interface, for example as part of an infrastructure equipment or a communications device.

[0138] Figure 9 ​The process begins in step S802, in which a context is established for subsequent compression of Ethernet frame headers. The context can be established by transmitting one or more frames to the peer decompressor in which the headers are not decompressed.

[0139] The peer decompressor can indicate that it has established the corresponding EHC context by an EHC acknowledgement.

[0140] In step S804, the compressor receives data comprising an Ethernet frame for transmission over the wireless access interface. The data can be received from another entity (e.g. a core network entity) and / or from another logical entity (e.g. a higher protocol layer).

[0141] The data can be associated with the context established in step S802 based on the destination of the data, a data bearer associated with the bearer, or by any other suitable means.

[0142] In step S806, the compressor determines whether EHC compression using the context established in step S802 is to be used for the data of step S804.

[0143] This determination can be made in accordance with one or more principles described herein. For example, the determination can be made based on the number of compressed frames transmitted within a transmission window whose headers are compressed in accordance with the context and the number of successful decompressions indicated by positive acknowledgements received from the peer decompressor within an associated reception window.

[0144] In addition, or alternatively, the determination can be made based on the number of frames that have been compressed using the context since the transmission of the last frame without EHC compression. In such embodiments, if the number of frames that have been compressed using the context since the transmission of the last frame without EHC compression exceeds a predetermined threshold, then it is determined that EHC compression using the context established in step S802 is not to be used for the data. Thus, embodiments of the present technology can ensure that desynchronisation of the compressor and decompressor can be avoided for long data sequences.

[0145] In some embodiments, the determination can be based on the number of frames that have not been compressed using the context since the transmission of the last frame with EHC compression. In some such embodiments, if the number of frames that have not been compressed using the context since the transmission of the last frame with EHC compression does not exceed a predetermined number, then it is determined that EHC compression using the context established in step S802 is not to be used for the data.

[0146] Thus, embodiments of the present technology can ensure that, in the event of an interruption in the use of compression, there is a high probability that the compressor and decompressor will be synchronised before compression is used again.

[0147] If it is determined that EHC compression using the context established at step S802 is to be used for the data received at step S804 ("Yes"), control proceeds to step S810.

[0148] At step S810, the Ethernet header within the data is compressed in accordance with the context established at step S802. The context can be updated accordingly.

[0149] Control then passes to step S812, at which the modified data (i.e. a copy or modified version of the data in which the header is compressed) is transmitted. The modified data can be transmitted via the wireless access interface, or, in the case that the compressor and transmitter are not integrated in a single entity, via any other suitable interface for transmission via the wireless access interface. Control can then return to step S804.

[0150] If it is determined that EHC compression using the context established at step S802 is not to be used for the data received at step S804 ("No"), control proceeds to step S808.

[0151] At step S808, the data is transmitted (or forwarded for transmission) without any EHC compression being applied to the Ethernet header.

[0152] Following step S808, in some embodiments control passes to step S802 and a new context is established. In some embodiments, control proceeds from step S808 to step S804. In some embodiments, control proceeds to step S802 or step S804 in accordance with a predetermined criterion.

[0153] According to embodiments of the present technique, corresponding procedures can be implemented at the decompressor.

[0154] In some embodiments, the decompressor can establish a new EHC context in response to receiving a frame in which the Ethernet header is not compressed and is associated with (e.g. transmitted with) a context ID.

[0155] The EHC context can be updated in response to receiving a compressed Ethernet header associated with a context ID corresponding to the EHC context.

[0156] In some embodiments, after determining not to apply EHC to one or more subsequent frames associated with the data stream in accordance with the existing context, and transmitting the one or more frames without applying EHC in accordance with the existing context, the compressor applies compression to one or more further subsequent frames in accordance with the existing context. By transmitting frames to which EHC is not applied, the context at the compressor and decompressor can be re-synchronised, so that the (re-synchronised) context can be used to decompress subsequent frames having compressed headers.

[0157] In some embodiments, the techniques herein are only applied to data frames associated with one or more of a quality of service requirement for successful reception probability exceeding a predetermined reliability threshold and a quality of service requirement for maximum allowed transmission delay being below a predetermined delay threshold. For example, the techniques can only be applied when a data frame is determined to be associated with a URLLC service, as specified in a particular release of the 3GPP specification.

[0158] In some embodiments of the present techniques, the processes described herein can be performed by an infrastructure equipment or a communications device of a wireless communications network. In some embodiments of the present techniques, the processes described herein can be performed by any suitable apparatus, such as a core network entity.

[0159] The above has given a description of example processes which combine sequences of steps and messages. However, the scope of the disclosure is not limited to such particular combinations, and in some embodiments various steps and messages described can be omitted, or combined in a different order, or modified. Features or steps described in the context of one example can be combined with features or steps described in the context of another example.

[0160] Thus, there has been described a method of processing data frames for transmission on a wireless access interface of a wireless communications system, the method comprising receiving a first data frame comprising a first protocol header associated with a data transmission medium access control (MAC) frame format within a local area network (LAN), applying header compression to the first data frame in accordance with a header compression context by compressing one or more protocol header fields of the first protocol header to form a first compressed data frame for transmission on the wireless access interface, receiving a second data frame comprising a second protocol header associated with the MAC frame format, and determining that no fields of the second protocol header will be compressed in accordance with the header compression context prior to transmission of the second data frame on the wireless access interface.

[0161] There is also described corresponding methods, apparatuses and circuitry for decompressing data frames.

[0162] It will be appreciated that, although to provide specific examples, the present disclosure focuses in some aspects on implementations based on LTE and / or 5G networks, the same principles can be applied to other wireless telecommunication systems. Thus, even though the terminology used herein is generally the same as or similar to that of the LTE and 5G standards, the present teachings are not limited to the current versions of LTE and 5G and can equally apply to any appropriate arrangements not based on LTE or 5G and / or in line with any other future releases of the LTE, 5G or other standards.

[0163] It can be noted that the various example methods discussed herein can rely on predetermined / predefined information in the sense that it is known to the base station and the communication device. It will be appreciated that such predetermined / predefined information can generally be established, for example, by definition in the standards governing operation of the wireless telecommunication system, or in previously exchanged signalling between the base station and the communication device, for example in system information signalling, or in association with radio resource control setup signalling, or in information stored in a SIM application. That is, the specific way in which the relevant predefined information is established and shared between the various elements of the wireless telecommunication system is not primary to the principles of operation described here. It can also be noted that the various example methods discussed here rely on information exchanged / transmitted between the various elements of the wireless telecommunication system, and it will be understood that such communication can generally be made in accordance with conventional techniques, for example in accordance with the specific signalling protocols and the type of communication channel used, unless the context otherwise requires. That is, the specific way in which the relevant information is exchanged between the various elements of the wireless telecommunication system is not primary to the principles of operation described here.

[0164] It will be appreciated that the principles described herein are not only applicable to certain types of communication devices, but can more generally be applied to any type of communication device, for example, the methods are not limited to machine type communication devices / IoT devices or other narrowband communication devices, but can more generally be applied, for example, to any type of communication device operating in respect of a wireless link to a communication network.

[0165] It will also be appreciated that the principles described herein are not only applicable to LTE-based wireless telecommunication systems, but to any type of wireless telecommunication system supporting the exchange of data including headers between a communication device and a base station or between different communication devices.

[0166] Other particular and preferred aspects of the present application are set out in the accompanying independent and dependent claims. It will be appreciated that features of the dependent claims can be combined with features of the independent claims in combinations other than those explicitly set out in the claims.

[0167] Accordingly, the preceding merely illustrates and describes example embodiments of the present application. As is readily appreciated by those skilled in the art, the present application can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present disclosure is therefore to be considered as merely illustrative and not restrictive, the scope of the application being indicated by the appended claims, along with the full scope of equivalents to which such claims are entitled. The disclosure, including any readily discernible variants thereof, defines the scope of the foregoing claims, such that no inventive subject matter is contributed to the public.

[0168] Various features of the present disclosure are defined by the following numbered paragraphs:

[0169] Paragraph 1. A method of processing data frames for transmission on a wireless access interface of a wireless communication system, the method comprising receiving a first data frame comprising a first protocol header, the first protocol header being associated with a media access control (MAC) frame format for data transmission within a local area network (LAN), applying header compression to the first data frame by compressing one or more protocol header fields of the first protocol header in accordance with a header compression context to form a first compressed data frame for transmission on the wireless access interface, receiving a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, and determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context prior to transmission of the second data frame on the wireless access interface.

[0170] Paragraph 2. The method of paragraph 1, the method comprising transmitting the first compressed data frame on the wireless access interface.

[0171] Paragraph 3. The method of paragraph 1 or paragraph 2, wherein the header compression context is associated with one or more of a destination address, a data bearer and a protocol data unit session, and wherein the first data frame and the second data frame are associated with one or more of the destination address, the data bearer and the protocol data unit session.

[0172] Paragraph 4. The method of any of paragraphs 1 to 3, the method comprising applying header compression to the second data frame by compressing one or more protocol header fields of the second protocol header to form a second compressed data frame for transmission on the wireless access interface of the wireless communication network, the header compression being in accordance with a further header compression context.

[0173] Paragraph 5. The method of paragraph 4, the method comprising transmitting the second compressed data frame on the wireless access interface.

[0174] Paragraph 6. The method of any of paragraphs 1 to 3, the method comprising transmitting the second data frame on the wireless access interface.

[0175] Paragraph 7. The method of any of paragraphs 1 to 6, the method comprising retransmitting the first data frame on the wireless access interface.

[0176] Paragraph 8. The method of any of paragraphs 1 to 7, the method comprising receiving, within a receive window, an indication that a first number of headers have been correctly decompressed by a peer decompressor, comparing the first number to a second number, the second number representing a number of frames transmitted during a corresponding transmit window, the frames having headers that have been compressed according to a context, and wherein determining that none of the fields of the second protocol header are to be compressed according to the header compression context comprises determining that the first number is less than the second number.

[0177] Paragraph 9. The method of paragraph 8, determining that none of the fields of the second protocol header are to be compressed according to the header compression context comprises determining that a difference between the first number and the second number exceeds a predetermined threshold.

[0178] Paragraph 10. The method of any of paragraphs 1 to 7, the method comprising receiving a feedback packet, the feedback packet comprising an indication that one or more frames were not correctly decompressed, wherein determining that none of the fields of the second protocol header are to be compressed according to the header compression context is in response to receiving the feedback packet.

[0179] Paragraph 11. The method of paragraph 10, wherein the feedback packet comprises an indication of an identification associated with the header compression context.

[0180] Paragraph 12. The method of paragraph 10, wherein the header compression context is associated with a first data stream and a second header compression context is associated with a second data stream, the first data stream and the second data stream being characterized by one or more of a destination address, a data bearer, and a protocol data unit session, the first data stream and the second data stream comprising data frames for transmission to a same device via a wireless access interface, and the feedback packet is not associated with a single header compression context, the method comprising, in response to receiving the feedback packet, determining that none of the fields of a header of a next frame of the second data stream are to be compressed according to the second header compression context.

[0181] Paragraph 13. The method of any of paragraphs 1 to 7, the method comprising, after applying the header compression to the first data frame, determining that no indication has been received, prior to a first time, that a frame has been correctly decompressed by a peer decompressor, wherein determining that none of the fields of the second protocol header are to be compressed according to the header compression context is in response to determining that no indication has been received, prior to the first time, that a frame has been correctly decompressed by a peer decompressor.

[0182] Paragraph 14. The method of paragraph 13, wherein the first time is a predetermined duration after the header compression is applied to the first data frame.

[0183] Paragraph 15. The method of paragraph 13, wherein the first time is a predetermined duration after the first compressed data frame is transmitted on the wireless access interface.

[0184] Paragraph 16. The method of any of paragraphs 1 to 15, the method comprising determining that header compression according to the header compression context has been applied to a plurality of consecutive frames including the first frame, wherein the determination that none of the fields of the second protocol header are to be compressed according to the header compression context is in response to determining that the number of consecutive frames exceeds a predetermined number.

[0185] Paragraph 17. The method of any of paragraphs 1 to 16, wherein the frame format is an Ethernet or IEEE 802.3 frame format.

[0186] Paragraph 18. The method of any of paragraphs 1 to 17, the method comprising forming a packet data convergence protocol (PDCP) protocol data unit (PDU) comprising the first compressed data frame.

[0187] Paragraph 19. The method of any of paragraphs 1 to 18, the method comprising encrypting the first compressed data frame.

[0188] Paragraph 20. The method of any of paragraphs 1 to 19, the method comprising applying an integrity protection function to the first compressed data frame.

[0189] Paragraph 21. The method of any of paragraphs 1 to 20, wherein the first data frame and the second data frame are associated with a quality of service requirement of a successful reception probability exceeding a predetermined reliability threshold, and a maximum allowed transmission delay below a predetermined delay threshold.

[0190] Paragraph 22. The method of any of paragraphs 1 to 21, wherein the first data frame and the second data frame are associated with an ultra-reliable low-latency communication (URLLC) service.

[0191] Paragraph 23. The method of any of paragraphs 1 to 2, the method comprising receiving a third data frame that has been transmitted on the wireless access interface, the third data frame comprising a protocol header associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN), the protocol header having been compressed according to a third header compression context, the header decompression being applied according to the third header compression context.

[0192] Paragraph 24. A method of processing data frames received on a wireless access interface of a wireless communication system, the method comprising receiving a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a protocol header associated with a media access control (MAC) frame format for data transmission within a local area network (LAN), the protocol header having been compressed in accordance with a first header compression context, applying header decompression in accordance with the first header compression context, receiving a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a protocol header associated with the MAC frame format for data transmission within the LAN, the protocol header not having been compressed in accordance with the first header compression context, the second data frame being associated with the first header compression context, and updating the first header compression context based on the second data frame.

[0193] Paragraph 25. Apparatus for use in a wireless communication network comprising an infrastructure equipment providing a wireless access interface, the apparatus comprising a controller configured so that the apparatus is operable to receive a first data frame comprising a first protocol header, the first protocol header being associated with a media access control (MAC) frame format for data transmission within a local area network (LAN), to apply header compression to the first data frame by compressing one or more protocol header fields of the first protocol header in accordance with a header compression context to form a first compressed data frame for transmission on the wireless access interface, to receive a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, and to determine that none of the fields of the second protocol header are to be compressed in accordance with the header compression context prior to transmission of the second data frame on the wireless access interface.

[0194] Paragraph 26. The apparatus of paragraph 25, the apparatus comprising a transmitter configured to transmit data via the wireless access interface, a receiver configured to receive signals, wherein the controller is configured to control the transmitter and the receiver so that the apparatus is operable to transmit the first compressed data frame on the wireless access interface.

[0195] Paragraph 27. The apparatus of paragraph 26, wherein the apparatus is the infrastructure equipment.

[0196] Paragraph 28. The apparatus of paragraph 26, wherein the apparatus is a communication device.

[0197] Paragraph 29. Circuitry for an apparatus for use in a wireless communications network, the wireless communications network comprising infrastructure equipment providing a wireless access interface, the circuitry comprising transmitter circuitry configured to transmit data via the wireless access interface, receiver circuitry configured to receive signals, and controller circuitry configured to control the transmitter circuitry and the receiver circuitry such that the apparatus is operable to: receive a first data frame comprising a first protocol header, the first protocol header being associated with a Media Access Control (MAC) frame format for data transmissions within a Local Area Network (LAN), to apply header compression to the first data frame by compressing one or more protocol header fields of the first protocol header in accordance with a header compression context to form a first compressed data frame for transmission on the wireless access interface, to receive a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, and to determine that none of the fields of the second protocol header are to be compressed in accordance with the header compression context prior to transmission of the second data frame on the wireless access interface.

[0198] Paragraph 30. An apparatus for use in a wireless communications network, the wireless communications network comprising infrastructure equipment providing a wireless access interface, the apparatus comprising a controller configured such that the apparatus is operable to: receive a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a protocol header associated with a Media Access Control (MAC) frame format for data transmissions within a Local Area Network (LAN), the protocol header having been compressed in accordance with a first header compression context, to apply header decompression in accordance with the first header compression context, to receive a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a second protocol header associated with the Media Access Control (MAC) frame format, the second protocol header not having been compressed in accordance with the first header compression context, the second data frame being associated with the first header compression context, and to update the first header compression context based on the second data frame.

[0199] Paragraph 31. Circuitry for an apparatus for use in a wireless communications network, the wireless communications network comprising infrastructure equipment providing a wireless access interface, the circuitry comprising controller circuitry configured such that the apparatus is operable to: receive a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a protocol header associated with a Media Access Control (MAC) frame format for data transmissions within a Local Area Network (LAN), the protocol header having been compressed in accordance with a first header compression context, to apply header decompression in accordance with the first header compression context, to receive a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a second protocol header associated with the Media Access Control (MAC) frame format, the second protocol header not having been compressed in accordance with the first header compression context, the second data frame being associated with the first header compression context, and to update the first header compression context based on the second data frame.

[0200] Further particular and preferred aspects of the present application are set out in the appended dependent and independent claims. It should be understood that the features of the dependent claims can be combined with the features of the independent claims in any combination other than those explicitly set out in the claims.

[0201] References

[0202] [1] 3GPP TS 38.300 v.15.2.0 “NR; NR and NG-RAN Overall Description; Stage 2 (Release 15)”, June 2018

[0203] [2] Holma H. and Toskala A, “LTE for UMTS OFDMA and SC-FDMA based radio access”, John Wiley and Sons, 2009

[0204] [3] 3GPP document R2-1901424

[0205] [4] 3GPP document R2-1909902

[0206] [5] 3GPP document R2-2000834

[0207] [6] 3GPP TS 38.323 v.16.0.0 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Packet Data Convergence Protocol (PDCP) specification (Release 16)”

Claims

1. A method of processing data frames for transmission on a wireless access interface of a wireless communication system, the method comprising receiving a first data frame comprising a first protocol header, the first protocol header being associated with a Media Access Control, MAC, frame format for data transmission within a Local Area Network, LAN, applying header compression to the first data frame by compressing one or more protocol header fields of the first protocol header in accordance with a header compression context to form a first compressed data frame for transmission on the wireless access interface, receiving a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context prior to transmission of the second data frame on the wireless access interface, receiving an indication within a reception window that a first number of headers have been correctly decompressed by a peer decompressor, and comparing the first number to a second number, the second number representing a number of frames transmitted during a corresponding transmission window, the header of the frame having been compressed in accordance with the header compression context, and wherein, determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context comprises determining that the first number is less than the second number.

2. The method of claim 1, the method comprising transmitting the first compressed data frame on the wireless access interface. The header compression context is associated with one or more of a destination address, a data bearer and a protocol data unit session, and wherein the first data frame and the second data frame are associated with one or more of the destination address, the data bearer and the protocol data unit session.

4. The method of claim 1, the method comprising applying header compression to the second data frame by compressing one or more protocol header fields of the second protocol header to form a second compressed data frame for transmission on a wireless access interface of a wireless communication network, the header compression being in accordance with a further header compression context.

5. The method of claim 4, the method comprising transmitting the second compressed data frame on the wireless access interface.

6. The method of claim 1, the method comprising transmitting the second data frame on the wireless access interface.

7. The method of claim 1, the method comprising retransmitting the first data frame on the wireless access interface. Determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context comprises determining that a difference between the first number and the second number exceeds a predetermined threshold.

9. The method of claim 1, the method comprising receiving a feedback packet, the feedback packet comprising an indication that one or more frames were not correctly decompressed, wherein, determining that none of the fields of the second protocol header are to be compressed in accordance with the header compression context is in response to receiving the feedback packet. The feedback packet comprises an indication of an identity associated with the header compression context.

3. The method of claim 1, wherein, ​ ​ ​ ​ ​ ​ ​ ​ ​ 8. The method of claim 1, wherein, ​ ​ ​ ​ 10. The method of claim 9, wherein, ​ 11. The method of claim 9, wherein, The header compression context is associated with a first data stream and a second header compression context is associated with a second data stream, The first data stream and the second data stream are characterized by one or more of a destination address, a data bearer and a protocol data unit session, The first data stream and the second data stream comprise data frames for transmission to a same device via the wireless access interface, and The feedback packet is not associated with a single header compression context, the method comprising determining, in response to receiving the feedback packet, that none of the fields of the header of the next frame of the second data stream is to be compressed according to the second header compression context.

12. The method of claim 1, the method comprising determining, after applying the header compression to the first data frame, that no indication has been received that a frame prior to a first time has been correctly decompressed by a peer decompressor, wherein determining that none of the fields of the second protocol header is to be compressed according to the header compression context is in response to determining that no indication has been received that a frame prior to the first time has been correctly decompressed by a peer decompressor.

13. The method of claim 12, wherein, The first time is a predetermined duration after applying the header compression to the first data frame.

14. The method of claim 12, wherein, The first time is a predetermined duration after transmitting the first compressed data frame on the wireless access interface.

15. The method of claim 1, the method comprising determining that header compression according to the header compression context has been applied to a plurality of consecutive frames including a first frame, wherein, determining that none of the fields of the second protocol header is to be compressed according to the header compression context is in response to determining that the number of consecutive frames exceeds a predetermined number.

16. The method of claim 1, wherein, The frame format is an Ethernet or IEEE 802.3 frame format.

17. The method of claim 1, the method comprising forming a packet data convergence protocol, PDCP, protocol data unit, PDU, comprising the first compressed data frame.

18. The method of claim 1, the method comprising encrypting the first compressed data frame.

19. The method of claim 1, the method comprising applying an integrity protection function to the first compressed data frame.

20. The method of claim 1, wherein, The first data frame and the second data frame are associated with a quality of service requirement of a successful reception probability exceeding a predetermined reliability threshold and a maximum allowed transmission delay below a predetermined delay threshold.

21. The method of claim 1, wherein, The first data frame and the second data frame are associated with an ultra-reliable low latency communication, URLLC, service.

22. The method of claim 1, the method comprising receiving a third data frame that has been transmitted on the wireless access interface, the third data frame comprising a protocol header associated with a media access control, MAC, frame format for data transmission within a local area network, LAN, the protocol header having been compressed according to a third header compression context, applying header decompression according to the third header compression context.

23. A method of processing data frames received on a wireless access interface of a wireless communication system, the method comprising to receive a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a first protocol header associated with a media access control, MAC, frame format for data transmission within a local area network, LAN, the first protocol header having been compressed according to a first header compression context, to apply header decompression according to the first header compression context, to receive a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a second protocol header associated with the MAC frame format for data transmission within a LAN, the second protocol header not having been compressed according to the first header compression context, the second data frame being associated with the first header compression context, to update the first header compression context based on the second data frame, to receive, within a receive window, an indication of a first number of headers that have been correctly decompressed by a peer decompressor, and to compare the first number with a second number, the second number representing a number of frames transmitted during a corresponding transmission window, a header of the frames having been compressed according to the header compression context, and wherein to determine that the first number is less than the second number.

24. An apparatus for use in a wireless communication network, the wireless communication network comprising an infrastructure equipment providing a wireless access interface, the apparatus comprising a controller configured to enable the apparatus to operate: to receive a first data frame comprising a first protocol header, the first protocol header being associated with a media access control, MAC, frame format for data transmission within a local area network, LAN, to apply header compression to the first data frame by compressing one or more protocol header fields of the first protocol header according to a header compression context, to form a first compressed data frame for transmission on the wireless access interface, to receive a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, and to determine that none of the fields of the second protocol header are to be compressed according to the header compression context prior to transmission of the second data frame on the wireless access interface, to receive, within a receive window, an indication of a first number of headers that have been correctly decompressed by a peer decompressor, and to compare the first number with a second number, the second number representing a number of frames transmitted during a corresponding transmission window, a header of the frames having been compressed according to the header compression context, and wherein to determine that none of the fields of the second protocol header are to be compressed according to the header compression context comprises determining that the first number is less than the second number.

25. The apparatus of claim 24, the apparatus comprising a transmitter configured to transmit data via the wireless access interface, a receiver configured to receive signals, wherein the controller is configured to control the transmitter and the receiver to enable the apparatus to operate to transmit the first compressed data frame on the wireless access interface.

26. The apparatus of claim 25, wherein, The apparatus is the infrastructure equipment.

27. The apparatus of claim 25, wherein, The apparatus is a communication device.

28. Circuitry for an apparatus for use in a wireless communications network, the wireless communications network comprising infrastructure equipment providing a wireless access interface, the circuitry comprising transmitter circuitry configured to transmit data via the wireless access interface, receiver circuitry configured to receive signals, and controller circuitry configured to control the transmitter circuitry and the receiver circuitry so that the apparatus is operable: to receive a first data frame comprising a first protocol header, the first protocol header being associated with a media access control, MAC, frame format for data transmission within a local area network, LAN, to apply header compression to the first data frame by compressing one or more protocol header fields of the first protocol header according to a header compression context, to form a first compressed data frame for transmission on the wireless access interface, to receive a second data frame comprising a second protocol header, the second protocol header being associated with the MAC frame format, and to determine that none of the fields of the second protocol header are to be compressed according to the header compression context prior to transmission of the second data frame on the wireless access interface, to receive, within a receive window, an indication of a first number of headers that have been correctly decompressed by a peer decompressor, and to compare the first number to a second number, the second number representing a number of frames transmitted during a corresponding transmission window, the headers of the frames having been compressed according to the header compression context, and wherein determining that none of the fields of the second protocol header are to be compressed according to the header compression context comprises determining that the first number is less than the second number.

29. An apparatus for use in a wireless communications network, the wireless communications network comprising infrastructure equipment providing a wireless access interface, the apparatus comprising a controller configured so that the apparatus is operable: to receive a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a first protocol header associated with a media access control, MAC, frame format for data transmission within a local area network, LAN, the first protocol header having been compressed according to a first header compression context, to apply header decompression according to the first header compression context, to receive a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a second protocol header associated with the media access control, MAC, frame format, the second protocol header not having been compressed according to the first header compression context, the second data frame being associated with the first header compression context, and to update the first header compression context based on the second data frame, to receive, within a receive window, an indication of a first number of headers that have been correctly decompressed by a peer decompressor, and to compare the first number to a second number, the second number representing a number of frames transmitted during a corresponding transmission window, the headers of the frames having been compressed according to the header compression context, and wherein determining that the first number is less than the second number.

30. Circuitry for an apparatus for use in a wireless communications network, the wireless communications network comprising an infrastructure equipment providing a wireless access interface, the circuitry comprising controller circuitry configured such that the apparatus is operable: to receive a first data frame that has been transmitted on the wireless access interface, the first data frame comprising a first protocol header associated with a media access control, MAC, frame format for data transmissions within a local area network, LAN, the first protocol header having been compressed in accordance with a first header compression context, to apply header decompression in accordance with the first header compression context, to receive a second data frame that has been transmitted on the wireless access interface, the second data frame comprising a second protocol header associated with the media access control, MAC, frame format, the second protocol header not having been compressed in accordance with the first header compression context, the second data frame being associated with the first header compression context, and to update the first header compression context based on the second data frame, to receive, within a receive window, an indication that a first number of headers have been correctly decompressed by a peer decompressor, and to compare the first number with a second number, the second number representing a number of frames transmitted during a corresponding transmission window, the headers of the frames having been compressed in accordance with the header compression context, and wherein to determine that the first number is less than the second number.

Images