Patent Description:
This applications claims priority to European Patent (EP) application number <CIT>.

Future wireless communications networks will be expected to support communications routinely and efficiently 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 future wireless communications networks will be expected to 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 may be deployed in very large numbers, for example low complexity devices for supporting the "The Internet of Things", and may typically be associated with the transmissions of relatively small amounts of data with relatively high latency tolerance.

An example of such a new service is referred to as Ultra Reliable Low Latency Communications (URLLC) services which, as its name suggests, requires that a data unit or packet be communicated with a high reliability and with a low communications delay. URLLC type services therefore represent a challenging example for both LTE type communications systems and <NUM>/NR communications systems.

The increasing use of different types of communications devices associated with different traffic profiles gives rise to new challenges for efficiently handling communications in wireless telecommunications systems that need to be addressed.

<NPL>, discusses Ethernet Header Compression. <CIT> discusses robust header compression for relay nodes.

Preferred empodiments are covered by the appended dependent claims.

The network <NUM> includes a plurality of base stations <NUM> connected to a core network part <NUM>. Each base station provides a coverage area <NUM> (e.g. a cell) within which data can be communicated to and from communications devices <NUM>. Data is transmitted from the base stations <NUM> to the communications devices <NUM> within their respective coverage areas <NUM> via a radio downlink. Data is transmitted from the communications devices <NUM> to the base stations <NUM> via a radio uplink. The core network part <NUM> routes data to and from the communications devices <NUM> via the respective base stations <NUM> and provides functions such as authentication, mobility management, charging and so on. Communications devices may also be referred to as mobile stations, user equipment (UE), user terminals, mobile radios, terminal devices, and so forth. Base stations, which are an example of network infrastructure equipment / network access nodes, may also be referred to as transceiver stations / nodeBs / e-nodeBs, g-nodeBs (gNB) and so forth. In this regard different terminology is often associated with different generations of wireless telecommunications systems for elements providing broadly comparable functionality. However, example embodiments of the disclosure may be equally implemented in different generations of wireless telecommunications systems such as <NUM> or new radio as explained below, and for simplicity certain terminology may be used regardless of the underlying network architecture. That is to say, the use of a specific term in relation to certain example implementations is not intended to indicate these implementations are limited to a certain generation of network that may be most associated with that particular terminology.

<FIG> is a schematic diagram illustrating a network architecture for a new RAT wireless communications network / system <NUM> based on previously proposed approaches which may also be adapted to provide functionality in accordance with embodiments of the disclosure described herein. The new RAT network <NUM> represented in <FIG> comprises a first communication cell <NUM> and a second communication cell <NUM>. Each communication cell <NUM>, <NUM>, comprises a controlling node (centralised unit) <NUM>, <NUM> in communication with a core network component <NUM> over a respective wired or wireless link <NUM>, <NUM>. The respective controlling nodes <NUM>, <NUM> are also each in communication with a plurality of distributed units (radio access nodes / remote transmission and reception points (TRPs)) <NUM>, <NUM> in their respective cells. Again, these communications may be over respective wired or wireless links. The distributed units <NUM>, <NUM> are responsible for providing the radio access interface for communications devices connected to the network. Each distributed unit <NUM>, <NUM> has a coverage area (radio access footprint) <NUM>, <NUM> where the sum of the coverage areas of the distributed units under the control of a controlling node together define the coverage of the respective communication cells <NUM>, <NUM>. Each distributed unit <NUM>, <NUM> includes transceiver circuitry for transmission and reception of wireless signals and processor circuitry configured to control the respective distributed units <NUM>, <NUM>.

A communications device or UE <NUM> is represented in <FIG> within the coverage area of the first communication cell <NUM>. This communications device <NUM> may thus exchange signalling with the first controlling node <NUM> in the first communication cell via one of the distributed units <NUM> associated with the first communication cell <NUM>. In some cases communications for a given communications device are routed through only one of the distributed units, but it will be appreciated in some other implementations communications associated with a given communications device may be routed through more than one distributed unit, for example in a soft handover scenario and other scenarios.

Thus example embodiments of the disclosure as discussed herein may be implemented in wireless telecommunication systems / networks according to various different architectures, such as the example architectures shown in <FIG> and <FIG>. It will thus be appreciated the specific wireless communications architecture in any given implementation is not of primary significance to the principles described herein. In this regard, example embodiments of the disclosure may be described generally in the context of communications between network infrastructure equipment / access nodes and a communications device, wherein the specific nature of the network infrastructure equipment / access node and the communications device will depend on the network infrastructure for the implementation at hand. For example, in some scenarios the network infrastructure equipment / access node may comprise a base station, such as an LTE-type base station <NUM> as shown in <FIG> which is adapted to provide functionality in accordance with the principles described herein, and in other examples the network infrastructure equipment / access node may comprise a control unit / controlling node <NUM>, <NUM> and / or a TRP <NUM>, <NUM> of the kind shown in <FIG> which is adapted to provide functionality in accordance with the principles described herein.

A more detailed illustration of a communications device <NUM> and an example network infrastructure equipment <NUM>, which may be thought of as a gNB <NUM> or a combination of a controlling node <NUM> and TRP <NUM>, is presented in <FIG>. As shown in <FIG>, the communications device <NUM> is shown to transmit uplink data to the infrastructure equipment <NUM> via grant free resources of a wireless access interface as illustrated generally by an arrow <NUM>. The UE <NUM> is shown to receive downlink data transmitted by the infrastructure equipment <NUM> via resources of the wireless access interface as illustrated generally by an arrow <NUM>. As with <FIG> and <FIG>, the infrastructure equipment <NUM> is connected to a core network <NUM> (which may correspond to the core network <NUM> of <FIG> or the core network <NUM> of <FIG>) via an interface <NUM> to a controller <NUM> of the infrastructure equipment <NUM>. The infrastructure equipment <NUM> may additionally be connected to other similar infrastructure equipment by means of an inter-radio access network node interface, not shown on <FIG>.

The infrastructure equipment <NUM> includes a receiver <NUM> connected to an antenna <NUM> and a transmitter <NUM> connected to the antenna <NUM>. Correspondingly, the communications device <NUM> includes a controller <NUM> connected to a receiver <NUM> which receives signals from an antenna <NUM> and a transmitter <NUM> also connected to the antenna <NUM>.

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

Correspondingly, the controller <NUM> of the communications device <NUM> is configured to control the transmitter <NUM> and the receiver <NUM> and may comprise processor circuitry which may in turn comprise various sub-units / sub-circuits for providing functionality as explained further herein. These sub-units may be implemented as discrete hardware elements or as appropriately configured functions of the processor circuitry. Thus the controller <NUM> may comprise circuitry which is suitably configured / programmed to provide the desired functionality using conventional programming / configuration techniques for equipment in wireless telecommunications systems. Likewise, the transmitter <NUM> and the receiver <NUM> may comprise signal processing and radio frequency filters, amplifiers and circuitry in accordance with conventional arrangements. The transmitter <NUM>, receiver <NUM> and controller <NUM> are schematically shown in <FIG> as separate elements for ease of representation. However, it will be appreciated that the functionality of these elements can be provided in various different ways, for example using one or more suitably programmed programmable computer(s), or one or more suitably configured application-specific integrated circuit(s) / circuitry / chip(s) / chipset(s). As will be appreciated the communications device <NUM> will in general comprise various other elements associated with its operating functionality, for example a power source, user interface, and so forth, but these are not shown in <FIG> in the interests of simplicity.

Conventionally, a wireless telecommunications network interfaces with external networks at the internet protocol (IP) layer. That is, a gateway of the wireless communications network receives IP packets in which the intended recipient communications device is identified by one or more destination address fields (such as IP destination address and/or port number). Similarly, outbound data is formed into IP packets, in which the source communications device is identified by a source IP address and/or source port number. (Note that this may be the case even if techniques such as network address translation are used, whereby the gateway or other entity modifies these addresses so that the address fields on inbound and/or outbound packets are modified at the logical boundary of the wireless communications network).

It will be appreciated that lower layer protocols may be used both within the wireless communications network, and externally to it, such as on links terminating at the gateway. However, headers associated with these protocols may conventionally be discarded before the encapsulated IP packet is forwarded.

Conventionally, wireless communications network have compressed the internet protocol (IP) header when the IP packet is transmitted over a wireless access interface by exploiting redundancy between the headers of sequential IP packets. In order to ensure that the IP header compressor at the transmitter and IP header decompressor at the receiver remain synchronized, the full header is transmitted, uncompressed, at regular intervals. Thus, it is possible for the receiver 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 may result in significantly improved efficiency in the use of communications resources on the wireless access interface.

Recently, there has been some interest in permitting interfacing of a wireless telecommunications network at a lower protocol layer. In particular, a gateway of the wireless telecommunications network may receive data frames formatted according to the Institute of Electrical and Electronic Engineers (IEEE) <NUM> frame format, or according to the Ethernet frame format, and may convey such frames internally within the wireless communications network, such that the complete Ethernet frame received at the gateway is made available to the end recipient. Similarly, a communications device may be able to construct a frame in accordance with such specifications for transmission outside of the wireless communications network.

It will be appreciated that the frame formats for IEEE <NUM> and for Ethernet are very similar, to the extent that their differences may be immaterial to the presently disclosed techniques, and thus the terms are used interchangeably within the present disclosure.

<FIG> illustrates an IEEE <NUM> MAC frame format, in accordance with the IEEE <NUM>. 1Q (<NUM>) specification.

The IEEE <NUM> MAC frame <NUM> comprises a MAC header <NUM>, MAC Client data and padding <NUM>, and a frame check sequence (FCS) <NUM>. The MAC header <NUM> comprises a preamble <NUM> and a start frame delimiter (SFD) <NUM> of length <NUM> octets and <NUM> octet respectively. There then follows a destination address field <NUM>, and a source address field <NUM>, each of <NUM> octets.

The MAC header <NUM> also comprises a Length/Type field <NUM> and a Tag Control information field <NUM>, each of two octets. Collectively, the Length/Type field <NUM> and Tag Control information field <NUM> may be referred to as a Q Tag Prefix.

The MAC header <NUM> also comprises a MAC client length/type field <NUM> of two octets, which may comprise a pre-determined value to indicate that the Tag Control information field <NUM> is present.

The Tag Control information field <NUM> may comprise a priority indication field <NUM> of <NUM> bits, a drop eligible indicator (DEI) bit <NUM>, and a virtual local area network (VLAN) identifier field <NUM> of <NUM> bits.

In some embodiments, for example where the IEEE <NUM>. 1Q (<NUM>) specification is not applicable, the MAC header <NUM> may not contain the Tag Control information field <NUM>.

<FIG> is a block diagram showing logical protocol entities within a communications device <NUM> and two infrastructure equipment 101a, 101b which may be configured to operate in accordance with example embodiments of the present technique. The communications device <NUM> may broadly correspond to the communications device <NUM> illustrated in <FIG> and described above. Each of the infrastructure equipment 101a, 101b may broadly correspond to the infrastructure equipment <NUM> illustrated in <FIG> and described above.

Protocol entities may be characterised by functions which they provide to other protocol entities. For example, physical layer (PHY) protocol entities <NUM>, <NUM> may control the transmitter <NUM> and receiver <NUM> to transmit and receive signals representing data on the wireless access interface. The PHY protocol entities <NUM>, <NUM> may thus provide an encoding and modulation function for data transmission, and a demodulation and decoding function for data reception.

The PHY protocol entities <NUM>, <NUM> may provide these services to respective medium access control (MAC) protocol entities <NUM>, <NUM>, which in turn provides services to respective radio link control (RLC) protocol entities <NUM>, <NUM>. The RLC entities <NUM>, <NUM> interact with a packet data convergence protocol (PDCP) entity <NUM>, which in turn receives data for transmission from, and passes received data to, a non-access stratum (NAS) layer <NUM>. The NAS layer may be an example of an `upper layer', with respect to the access stratum (AS) layer comprising the PDCP protocol entities <NUM>, <NUM> and lower layer protocol entities. In addition, an SDAP (Service Data Adaptation Protocol) protocol entity, not shown in <FIG> for conciseness, may reside on top of (i.e. at a higher logical layer than) the PDCP protocol entities <NUM>, <NUM>.

In some embodiments, the communications device <NUM> operates in single connectivity mode, whereby only one instance each of the RLC protocol entities <NUM>, <NUM>, MAC protocol entities <NUM>, <NUM> and PHY protocol entities <NUM>, <NUM> are active; for example, only the RLC entity <NUM>, MAC protocol entity <NUM> and PHY protocol entity <NUM> are active. Data may be communicated between the communications device <NUM> and the infrastructure equipment 101a via a first wireless access interface <NUM>.

In some embodiments of the present technique, the communications device <NUM> shown in <FIG> may be configured to act in a dual connectivity (DC) mode of operation, in which data may be communicated between the communications device and first and second infrastructure equipment 101a, 101b substantially simultaneously. The first infrastructure equipment 101a may act as a master node (MN) and the second infrastructure equipment 101b may act as a secondary node (SN). In the DC mode, each of the infrastructure equipment 101a, 101b has an RLC entity <NUM>, <NUM> which has as a peer one of the RLC entities <NUM>, <NUM> of the communications device <NUM> per radio bearer. Accordingly, each of the infrastructure equipment 101a, 101b has a MAC protocol entity <NUM>, <NUM>, being the peer of the corresponding MAC entity <NUM>, <NUM> of the communications device <NUM>, and a PHY entity <NUM>, <NUM> being a peer of the corresponding PHY entity <NUM>, <NUM> of the communications device <NUM>.

Thus, unlike in the single connectivity mode, in dual connectivity in the communications devices <NUM> two sets of RLC, MAC and PHY protocol instances are active, for the communication of data directly with the MN 101a via the first wireless access interface <NUM> and via the SN 101b via a second wireless access <NUM> for a single radio bearer.

In both dual connectivity and single connectivity mode, at the PDCP protocol layer, the single PDCP entity <NUM> of the communications device <NUM> has as its peer a single PDCP entity <NUM> of the master node 101a.

In dual connectivity, the PDCP entity <NUM> of the MN 101a interacts with both the RLC entity <NUM> of the MN 101a and the RLC entity <NUM> of the SN 101b via an inter-radio access network node interface <NUM>, which may be an Xn or X2 interface.

Each protocol entity in the communications device <NUM> may be implemented by the controller <NUM> in combination with the receiver <NUM> and transmitter <NUM> of the communications device.

Similarly, each protocol entity in the infrastructure equipment 101a, 101b, may be implemented by the respective controller <NUM> in combination with the respective receiver <NUM> and transmitter <NUM> of the infrastructure equipment.

In order to improve reliability of transmission of data between the communications device <NUM> and the wireless communications network, each of the PDCP entities <NUM>, <NUM> may conventionally provide duplication functionality for transmitted data, so that data received from upper layers may be transmitted both via the MN 101a and via the SN 101b. Similarly, each of the PDCP entities <NUM>, <NUM> may provide de-duplication functionality to ensure that only a single instance of the upper layer data is passed to the upper layers (for downlink data) or forwarded to the core network <NUM> (for uplink data).

The use of header compression in combination with duplication at the PDCP layer may provide high transmission reliability while making efficient use of radio resources.

The inventors of the present disclosure have nevertheless identified a need to provide improved techniques for the reliable of data transmitted using header compression techniques, while making efficient use of radio resources, in particular for the transmission of Ethernet frames.

Thus, there is provided a method of processing data for transmission in a wireless communications system, the method comprising identifying within the data a data frame having a protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN), determining a selected profile for header compression, the profile being selected from a plurality of predetermined profiles, each of the plurality of predetermined profiles specifying a subset of the protocol header fields, and applying compression to a subset of the protocol header fields in accordance with the selected profile to form a compressed data frame for transmission on a wireless access interface of the wireless communications network.

There is further provided A method of processing data transmitted in a wireless communications system, the method comprising identifying within the data a compressed data frame comprising protocol header fields, determining a selected profile for header compression, the profile being selected from a plurality of predetermined profiles, each of the plurality of predetermined profiles specifying a subset of protocol header fields, and applying decompression to a subset of the protocol header fields in accordance with the selected profile to form a decompressed protocol header, the decompressed protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN).

Conventionally, where duplication is enabled together with IP header compression, the duplication is performed (by the PDCP entity) after the IP header compression. As such, the same (compressed) IP header information is sent on both 'legs' (i.e. via the SN, and direct from the MN to the communications device).

However, the radio channels are error prone and, although duplication may allow the transmission of multiple copies of packets, there remains a possibility that one or both instances of the data are corrupted and/or that the compressor and decompressor are out of sync with regards to the compression algorithm so that header decompression may fail.

In accordance with embodiments of the present technique, there are provided techniques to allow a selection of a profile specifying a subset (or all, or none) of the Ethernet header fields to be compressed, from a plurality of profiles. Thus, the appropriate profile may be selected in order to provide reliable data transmission while making efficient use of radio resources.

There are further provided in some embodiments techniques in which a different compression profile is applied to data frames which are to be transmitted using different 'legs', i.e. where the transmitter-receiver pair on the wireless access interface is different. Appropriate profiles may be selected jointly for each leg, to provide reliable data transmission while making efficient use of radio resources. In such embodiments, a single PDCP entity in the wireless communications network may be peered with a corresponding PDCP entity in the communications device, to avoid additional complexity of multiple PDCP protocol entities. In some such embodiments, the data frames are duplicated and the duplicate copies are compressed independently of each other, i.e. using potentially different compression profiles.

According to embodiments of the present technique, compression and decompression of the Ethernet frame header is carried out in accordance with a selected profile, the selected profile identifying zero, one, or more Ethernet header fields which are to be subject to compression.

In some embodiments, the selected profile is selected from a plurality of predetermined profiles. In some embodiments, the selected profile is selected from three or more predetermined profiles, wherein a first predetermined profile specifies that no header fields are to be compressed, a second predetermined profile specifies that a first plurality of header fields are to be compressed, and the third profile specifies that a second plurality of header fields are to be compressed, the second plurality being a subset of the first plurality of header fields and containing fewer fields than the first plurality.

In some embodiments, each profile is associated with a profile identifier (Profile ID).

In some embodiments, one of more of the predetermined profiles may specify fields as shown in Table <NUM>, for the case where <NUM>. 1Q is applied.

In some embodiments, where <NUM>. 1Q is not applied, each predetermined profile may specify whether or not the length/type field (or portion(s) thereof) is to be compressed. In some embodiments, the predetermined profiles may comprise a profile in which no header fields are compressed, a profile in which a plurality of header fields are compressed, and a further profile in which a subset of the plurality of header fields are compressed; for example, the predetermined profiles may correspond to those associated with the profile IDs 0x0000, 0x0004, and 0x0002.

In some embodiments, the compression is carried out at a PDCP protocol entity.

Embodiments in which a predetermined profile specifies one or more header fields, excluding the length/type and/or QTag prefix, may permit a protocol entity at a lower protocol layer than that at which the compression is applied to apply appropriate prioritisation, scheduling and/or encoding, based on a mapping between an (uncompressed) field in the Ethernet header and a rule for such prioritisation, scheduling and/or encoding. For example, there may be established a mapping between a particular radio bearer on the wireless access interface and a value of an Ethernet header field. By refraining from compressing that Ethernet header field at a higher layer, a mapping of the Ethernet frame to the particular radio bearer may be carried out at a lower layer, and the frame may accordingly be transmitted using the radio bearer.

For example, embodiments in which a predetermined profile specifies one or more header fields, excluding the VLAN ID, may permit a protocol entity at a lower protocol layer than that at which the compression is applied, such as a MAC protocol entity, to identify a service (such as the URLLC service) associated with the frame, where the VLAN ID is associated with the service. A service may be associated with particular quality of service requirements. By mapping an Ethernet frame to a service, a transmitting entity (such as the infrastructure equipment 101a, 101b)) can accordingly transmit the frame in accordance with the quality of service requirements associated with that service.

Embodiments in which a predetermined profile specifies both the destination address and the source address fields may provide efficient use of communications resources, since the destination and source addresses may not be relevant over the wireless access interface and may be recoverable at the receiver.

In some embodiments, the compression profile for communication of data between the communications device <NUM> and the first infrastructure equipment 101a is selected by the infrastructure equipment, such as the first infrastructure equipment 101a.

The selected profile may be indicated to the communications device <NUM> by means of RRC configuration, by MAC layer signalling, or in layer <NUM> signalling.

In some embodiments, the selected profile may be modified by the infrastructure equipment 101a during an ongoing connection. The modified profile may be indicated to the communications device <NUM> by means of RRC configuration, by MAC layer signalling, or in layer <NUM> signalling.

In some embodiments, the infrastructure equipment 101a comprises a compressor as described herein, and the communications device <NUM> comprises a decompressor as described herein. Additionally or alternatively, in some embodiments, the infrastructure equipment 101a comprises a decompressor as described herein, and the communications device <NUM> comprises a compressor as described herein.

In some embodiments, the infrastructure equipment 101a may change which profile is selected based on one or both of feedback of radio conditions and feedback regarding a success/failure of decompressor. Feedback on the radio conditions may comprise measurement reports transmitted by the communications device <NUM> to the infrastructure equipment 101a. Similarly, feedback regarding a success or failure of a decompressor may comprise an indication of whether one or more previous decompression attempts has been successful or has failed. The radio conditions may comprise a quality measurement associated with a radio channel of the wireless access interface. The quality measurement may comprise a signal to noise ratio, a received signal strength or an indicator based on such a ratio or strength.

In some embodiments, an indication of success/failure of the decompressor in respect of one or more downlink (respectively uplink) frames is indicated in a PDCP header associated with an uplink (respectively downlink) frame.

Modifying the selected profile in response to channel conditions and/or decompressor success or failure may result in more efficient use of the resources of the wireless access interface.

In some embodiments, a given connection (e.g. associated with a PDU session) may be associated with a subset of the predetermined plurality of profiles. For example, a PDU session may be associated with only the profiles 0x0000, 0x0002 and 0x0004 of Table <NUM>.

In some embodiments, where no duplication is used for the Ethernet frames, security (i.e. one or both of ciphering and integrity) may be activated. That is, encryption may be applied and/or an integrity protection field may be added after the compression of the Ethernet header.

<FIG> illustrates a flowchart for a process of compressing frames in accordance with embodiments of the present technique.

The process starts at step S602 in which it is identified that data comprising an Ethernet frame is available for transmission. The data may have been received from upper protocol layers within the same entity, for example from a NAS protocol entity, or the data may have been received from another entity of the wireless communications network, for example the core network entity <NUM>.

At step S604, it is determined which profile is to be used for compression. As described elsewhere the profile may indicate which subset of header fields are to be compressed. The profile may be determined based on an indication received from a peer entity, such as an infrastructure equipment of the wireless communications network. Alternatively the profile may be determined in accordance with a process for determining a profile that is illustrated in <FIG> and described below.

At step S606 header fields are selected based on the profile determined at step S604. Each profile may be identified by a corresponding profile identifier, which corresponds to a subset of the Ethernet frame header fields which are to be compressed. An example of profiles and their corresponding identifiers is shown above in Table <NUM>. For example, where the selected profile is the profile having the identifier 0x0001, then the selected fields comprise the destination address field <NUM>, the source address field <NUM>, the length/type field <NUM> and portions of the tag control information field <NUM>. However according to the profile 0x0001, the VLAN ID <NUM> is not one of the selected header fields and therefore will not be compressed.

At step S608, the selected header fields are compressed. The compression may be in accordance with conventional header compression techniques, such as those conventionally applied to IP headers. These may include state based compression techniques wherein the result of the compression depends on not only the contents of the selected header fields of the present Ethernet frame, but also on the contents of one or more previous Ethernet frames which have been compressed. It is important to note that depending on the selected profile some header fields may not be compressed. As described above for example where the selected profile has the identifier 0x0001, then the VLAN ID field is not compressed. By refraining from compressing certain header fields, these fields may be made available, uncompressed, to lower protocol layers which may use the contents of the uncompressed fields for their own purposes for example a medium access control (MAC) protocol entity may use the VLAN ID field to select two identifying quality of service requirements associated with the Ethernet frame. Hence the Ethernet frame may be scheduled appropriately for transmission on a wireless access interface.

Subsequently, at step S610, a compressed Ethernet frame is formed using the compressed header fields, the uncompressed header fields and the uncompressed MAC data <NUM>. Optionally at step S612, ciphering and/or integrity protection may be applied to the compressed Ethernet frame.

At step S614, a PDCP PDU is formed comprising the compressed Ethernet frame which may be ciphered and/or integrity protected and a sequence number. In some embodiments, the PDCP PDU may comprise an indication of the profile used for the compression as determined at step S604.

At step S616, the PDCP PDU is transmitted on a wireless access interface.

Steps S602 to S616 may be carried out by a PDCP protocol entity such as the PDCP entity <NUM> of the first infrastructure equipment 101a, or the PDCP entity <NUM> of the communications device <NUM>.

It will be appreciated that, in accordance with conventional techniques, the PDCP PDU may be further processed by protocol entities at lower layers such as the RLC protocol entity <NUM>, <NUM>, the MAC protocol entity <NUM>, <NUM> and the PHY protocol entity <NUM>, <NUM> before being transmitted as signals over the wireless access interface.

<FIG> illustrates a process in accordance with embodiments of the present technique, by which a profile for the compression of Ethernet frames may be selected. The process of <FIG> may be carried out for example by the infrastructure equipment 101a. The process of <FIG> may be initiated in response to a determination that a PDU session having a type corresponding to Ethernet frames is to be established for the communications device <NUM> in the wireless communications network.

The process starts at step S702, in which initially a profile is selected based on predetermined rules, for example based on a default compression profile. Subsequently at step S704, an indication of the selected profile is transmitted to the communications device <NUM>.

At step S706, the channel conditions applicable to transmissions of the wireless access interface between the infrastructure equipment and the communications device are determined. This may comprise, for example, measurements of signals received from the communications device <NUM>, or receiving results of measurements performed by the communications device <NUM> of downlink signals.

The process continues with step S708, in which the infrastructure equipment 101a receives from the communications device <NUM> an indication of a status of an Ethernet frame decompressor. The decompressor status may indicate whether or not the communications device <NUM> has been successful in decompressing previously transmitted compressed Ethernet frames.

Subsequently at step S710, the infrastructure equipment 101a determines whether or not conditions for modifying the selected compression profile are met. If they are not, then control passes to step S706. If the conditions are met at step S710, then control returns to step S702, in which the selected profile is modified based on one or both of the monitored channel conditions and the received indication of the decompressor status.

For example, where channel conditions are determined to have deteriorated at step S706, then the new selected profile may be one which compresses fewer Ethernet header fields, or possible no Ethernet header fields. Conversely, for example, if the received decompressor status indicates that a high proportion of previously received Ethernet frames have been decompressed successfully by the communications device, then the new selected profile may correspond to a profile in which more Ethernet header frames are compressed.

The process then continues with step S704 and the process may generally continue while the PDU session is ongoing.

In some embodiments, one or more of steps S708 and S706 may be omitted, and the conditions for modifying the selected profile modified accordingly.

In some embodiments, a determination to modify the selected profile may be based at least in part on a number of frames that have been sent consecutively using the currently selected profile. The determination may be further based on the currently selected profile. For example, in some embodiments, if <NUM> frames have been sent in accordance with a particular profile, according to which one or more header frames are compressed, then a next two frames may be transmitted using a different profile, before switching back to the previous profile. In some such embodiments, according to the different profile, no header frames are compressed.

As such, there may be transmitted sequences of frames, comprising ten frames having some or all header fields compressed, followed by two frames having no header compression applied, and so on.

In some embodiments, the process of <FIG> may be applied when the data communication is by means of dual connectivity. As will be described below, in some embodiments, a different profile may be configured for each 'leg' of the dual connectivity and thus in step S702 two profiles may be selected, one for each leg of the dual connectivity. Accordingly, steps S704, S708 and S710 may be carried out in respect of each leg independently, or both legs jointly.

<FIG> illustrates a message sequence chart in accordance with some embodiments of the present technique.

The process illustrated in <FIG> starts at step S802 in which the core network part <NUM> transmits an PDU session setup indication <NUM> to the gNodeB 101a. The PDU session setup indication <NUM> transmitted by the core network part <NUM> at step S802 may comprise a PDU session type indicator <NUM> which indicates that the PDU session to be set up is of an Ethernet type.

In response to receiving the PDU session setup indication <NUM>, the gNodeB <NUM> may transmit, at step S804, a compression configuration indication <NUM> indicating of one or more compression profiles for the compression of the Ethernet frame headers. In some embodiments the compression configuration indication <NUM> is transmitted as part of RRC configuration, or is transmitted at the MAC layer, or may be indicated by means of layer <NUM> signalling. The compression configuration indicator <NUM> may indicate one or more profile numbers, which may correspond to predetermined profiles as previously described.

Subsequently the communications device <NUM> and the gNodeB <NUM> may communicate user data between them, in which the Ethernet headers may be compressed in accordance with the profile or profiles indicated by the compression configuration indicator <NUM>. In some embodiments, even when Ethernet frame header compression is configured for one or more of the Ethernet frame header fields, some data may be sent with an uncompressed Ethernet frame header, in order to ensure that the compressor and decompressor remain synchronised.

For example user data transmitted at steps S806 and S808 may comprise a compressed Ethernet frame header, while user data transmitted subsequently at step S810 is transmitted without any compression being applied to the Ethernet header.

In some embodiments, duplication is applied to the data to provide increased reliability of transmission.

As shown in <FIG>, duplication may be carried at the PDCP entity of a MN 101a and the two resulting instances may be transmitted over different radio channels by the MN 101a and the SN 101b. In the uplink, duplicate instances may be transmitted by the communications device <NUM> to the MN 101a and the SN 101b.

In some embodiments of the present technique, duplication occurs prior to header compression. Thus, in some embodiments, different header compression profiles may be applied to each copy of the Ethernet frame.

<FIG> shows a process which may be carried out by the PDCP entity <NUM> of the MN 101a, or the PDCP entity <NUM> of the communications device <NUM>.

The process starts at step S1202, in which data is received from upper layers for transmission; this may comprise receiving the data from the core network part <NUM> in the case of the MN 101a.

The Ethernet frame is identified and a sequence number (SN) is applied at step S1204. At step S1206, duplicate copies of the Ethernet frame are formed.

At step S1208, the first copy, for transmission on a first 'leg', comprising a radio link between the MN 101a and the communications device <NUM> is selected. At step S1210, the compression profile applicable to transmissions on the first leg is determined.

Subsequently, at step S1212, steps S606 to S614 of the process illustrated in <FIG> and described above are carried out in respect of the selected copy of the frame. In some embodiments, step S612 is not carried out; that is, no encryption or integrity protection is applied to the frame.

At step S1214, PDCP PDU comprising the copy of the frame is passed to the RLC entity associated with the corresponding leg.

For downlink data where the leg is that between the MN 101a and the communications device <NUM>, the PDCP PDU comprising the copy of the frame is passed to the RLC entity <NUM> of the MN 101a. Where the leg is that between the SN 101b and the communications device <NUM>, the PDCP PDU comprising the copy of the frame is passed to the RLC entity <NUM> of the SN 101b via the interface <NUM>.

At step S1216, if both legs have been considered, then control passes to step S1218 and the process ends. If not, then control passes to step S1220, in which the copy associated with the second leg is considered, and the process then continues with step S1210 in respect of the copy associated with the second leg.

In some embodiments, the selected profile determined at step S1210 may be different for each leg. In some embodiments, the profile corresponding to at least one of the legs specifies that compression is not to be applied to any of the header fields, thus ensuring that the possibility of the compressor and decompressor losing synchronisation is significantly decreased.

At step S614 within step S1212, the same PDCP header is added to form each instance of the PDCP PDU, unless the profile is indicated within the PDCP header, in which case only that indication may differ.

Corresponding to the process shown in <FIG> and described above for forming PDCP PDUs for transmission, an analogous process may be implemented in respect of received PDCP PDUs.

Specifically, on the receiver side, the packet is passed on to a reordering and duplicate discard block within the PDCP protocol entity <NUM>, <NUM>. Based on the PDCP header, it is determined if the received packet is a duplicate of one previously received. If so, then it will be discarded. If, on the other hand, it is the first copy of a particular packet which has been received, then it is passed onto a decompression entity. The decompression entity determines the compression profile used on the sender side, which may depend on the RLC entity at which the packet was received. Accordingly, the decompression entity may determine the RLC entity where it was received. Alternatively, the PDCP header may comprise an indication explicitly indicating the header compression profile used by the transmitter.

Where a profile has been indicated to the receiver both by means of RRC configuration and within the PDCP header, then in some embodiments the profile indicated in PDCP header takes priority.

The later part will require changes to PDCP header to indicate the Ethernet header compression profile used by the transmitter.

A benefit of using different profiles is that the communications resources needed to transmit the data may be reduced by compressing the packets while at the same time avoiding any possibility of compression state mismatch between sender and receiver.

In some embodiments, the infrastructure equipment 101a configures different header compression profiles for communicating data between the communications device <NUM> and the MN 101a by means of RRC signalling.

In some embodiments, the header compression profiles may be changeable at the time of a handover, in order to reflect different capabilities or rules applied by a target infrastructure equipment.

In some embodiments, dual connectivity may be configured, so that particular data may be transmitted either directly between the MN 101a and the communications device <NUM>, or via the SN 101b. In other words, duplication does not occur. Accordingly, the process of <FIG> may be adapted by removing steps S1206, S1216 and S1220, and by replacing step S1208 by step S1208a, in which it is determined on which leg the data is to be transmitted.

As described above, in general a selected compression profile may be adapted based on decompressor success and/or radio channel conditions. In some embodiments, the selected compression profile is adapted in accordance with a predetermined algorithm known to both the transmitter and the receiver.

For example, according to the algorithm, the profile may be adjusted to the adjacent profile in which the number of fields to which compression is applied is increased, if more than <NUM> of the last <NUM> Ethernet headers could not be successfully decompressed.

The algorithms and/or their parameters may be configured by the MN 101a by RRC configuration.

Conventionally, when duplication is applied, a timer may be used to determine whether or not a given packet should be duplicated. In some embodiments of the present technique, the same timer is used to adjust the selected compression profile for each leg. Specifically, for example, a timer used to determine if a packet should be duplicated may in some embodiments, also be used to decide if a different compression profile should be used on different legs.

Accordingly, where it is determined that it is unlikely that duplication will occur based on the timer, it may be determined to apply compression to at least some fields of the header of the frame, regardless of the leg on which the frame is to be transmitted.

In some embodiments, the actual profile used on each leg may be changed dynamically using a MAC control element (CE).

In some embodiments, the techniques described herein are applied only in respect of data frames being associated with one or more of a quality of service requirement for a probability of successful reception which exceeds a predetermined reliability threshold, and a quality of service requirement for a maximum permitted latency of transmission which is below a predetermined latency threshold. For example, one or more techniques may be applied only if a data frame is determined to be associated with a URLLC service, as specified in a particular release of a 3GPP specification.

Above have been given descriptions of example processes combining sequences of steps and messages in combination. The scope of the present disclosure is not, however, limited to such specific combinations and in some embodiments, various of the steps and messages described may be omitted, or combined in a different order, or modified, insofar such alterations are encompassed by the scope of the invention as defined by the appended claims.

Thus there has been described a method of transmitting data in a wireless communications system, the method comprising identifying within the data a data frame having a protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN), determining a selected profile for header compression, the profile being selected from a plurality of predetermined profiles, each of the plurality of predetermined profiles specifying a subset of the protocol header fields, and applying compression to a subset of the protocol header fields in accordance with the selected profile to form a compressed data frame for transmission on a wireless access interface of the wireless communications system.

There has further been described a method of receiving data in a wireless communications system, the method comprising receiving the data via a wireless access interface, the data comprising a compressed data frame, determining a selected profile for header compression, the profile being selected from a plurality of predetermined profiles, each of the plurality of predetermined profiles specifying a subset of the protocol header fields, and applying decompression to a subset of the protocol header fields in accordance with the selected profile to form a decompressed protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN).

It may be noted various example approaches discussed herein may rely on information which is predetermined / predefined in the sense of being known by both the base station and the communications device. It will be appreciated such predetermined / predefined information may in general be established, for example, by definition in an operating standard for the wireless telecommunication system, or in previously exchanged signalling between the base station and communications devices, 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 to say, the specific manner in which the relevant predefined information is established and shared between the various elements of the wireless telecommunications system is not of primary significance to the principles of operation described herein.

It may further be noted various example approaches discussed herein rely on information which is exchanged / communicated between various elements of the wireless telecommunications system and it will be appreciated such communications may in general be made in accordance with conventional techniques, for example in terms of specific signalling protocols and the type of communication channel used, unless the context demands otherwise. That is to say, the specific manner in which the relevant information is exchanged between the various elements of the wireless telecommunications system is not of primary significance to the principles of operation described herein.

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

It will further be appreciated that the principles described herein are not applicable only to LTE-based wireless telecommunications systems, but are applicable for any type of wireless telecommunications system that supports a random access procedure comprising an exchange of random access procedure messages between a communications device and a base station.

Further particular and preferred aspects of the present invention are set out in the accompanying independent and dependent claims. It will be appreciated that features of the dependent claims may be combined with features of the independent claims in combinations other than those explicitly set out in the claims.

Claim 1:
A method of processing data for transmission in a wireless communications system, the method comprising
identifying (S602) within the data a data frame having a protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control, MAC, frame format for data transmission within a local area network, LAN,
determining (S604) a selected profile for header compression, the profile for header compression being selected from a plurality of predetermined profiles, each of the plurality of predetermined profiles specifying a subset of the plurality of protocol header fields,
applying (S608) compression to a subset of the plurality of protocol header fields in accordance with the selected profile for header compression to form a compressed data frame for transmission on a wireless access interface of the wireless communications system,
transmitting (S614) an indication of the selected profile for header compression, receiving (S708) a decompressor status indication, the decompressor status indication indicating whether an attempt to apply decompression to the compressed data frame to reconstruct the protocol header fields was successful,
determining (S710) whether conditions for modifying the selected profile for header compression are satisfied, wherein the conditions for modifying the selected profile for header compression comprise conditions based on the received decompressor status, and, if so,
identifying, within subsequent data, another data frame having a protocol header comprising the plurality of protocol header fields and being associated with the MAC frame format for data transmission within the LAN,
determining a modified selected profile for header compression by selecting another one of the plurality of predetermined profiles,
applying compression to a subset of the plurality of protocol header fields of the other data frame in the subsequent data in accordance with the modified selected profile for header compression to form another compressed data frame for transmission on the wireless access interface of the wireless communications system, and
transmitting an indication of the modified selected profile for header compression.