WO2019226098A1

WO2019226098A1 - Methods, transmitting node and receiving user equipment for handling a pdu based on 3gpp release, version or feature

Info

Publication number: WO2019226098A1
Application number: PCT/SE2019/050447
Authority: WO
Inventors: Marco BELLESCHI; Mattias BERGSTRÖM; Mats Folke
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-05-21
Filing date: 2019-05-16
Publication date: 2019-11-28

Abstract

A transmitting node (600), a receiving User Equipment, UE, (602) and methods therein, for enabling or supporting wireless communication. The transmitting nodecreates (6:1) a Protocol Data Unit, PDU, with multiple components, and arranges(6:1) the components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU. The PDU with the arranged components is transmitted (6:2) to the receiving UE(s). The receiving UE then processes (6:3) the components in the PDU that the receiving UE comprehends according to said arranged components, and discards (6:3) any component in the PDU that the receiving UE does not comprehend.(Fig. 6)

Description

METHODS, TRANSMITTING NODE AND RECEIVING USER EQUIPMENT FOR

HANDLING A PDU BASED ON 3GPP RELEASE, VERSION OR FEATURE

Technical field

The present disclosure relates generally to a transmitting node, a receiving User Equipment, UE, and methods therein, for enabling or supporting wireless communication.

Background

In this disclosure, the term“User Equipment, UE” is used to represent any communication entity capable of radio communication with a wireless network by sending and receiving radio signals, such as e.g. mobile telephones, tablets, laptop computers and Machine-to-Machine, M2M, devices, also known as

Machine Type Communication, MTC, devices. Another common generic term in this field is“wireless device” which could be used herein as a synonym for User Equipment, UE. The term“transmitting node” used herein may be a transmitting UE or a network node, such as a base station or eNB depending on the terminology,

communicating with a receiving UE. Further, a network node belonging to a wireless network and being capable of wireless communication with UEs is referred to herein as an eNB which is a common term used by the third Generation Partnership Project, 3GPP. In this disclosure, the term“PDU” may denote a

Packet Data Unit or a Protocol Data Unit, depending on the terminology applied.

During Release 12, the Long-Term Evolution (LTE) standard has been extended with support of device to device (D2D), also referred to as“sidelink”, features targeting both commercial and Public Safety applications. Applications enabled by Rel-12 LTE using D2D communication include device discovery, where devices are able to sense the proximity of another device and associated application by broadcasting and detecting discovery messages that carry device and application identities. Another application using D2D communication comprises direct communication based on physical channels terminated directly between devices. In 3GPP, all of these applications are defined under a framework called Proximity Services (ProSe).

Some potential extensions of the ProSe framework include support of vehicle to other node x, denoted V2x, communication, which includes any combination of direct communication between a vehicle and another node such as other vehicles, pedestrians, and infrastructure. It should be noted that in this disclosure“V2x” denotes any of vehicle to vehicle V2V, vehicle to infrastructure V2I, vehicle to pedestrian V2P, and vehicle to network V2N, which will all be described in more detail below. V2x communication may take advantage of a network infrastructure, when available, but at least basic V2x connectivity should be possible even in case of lack of coverage. Providing an LTE-based V2x interface may be economically advantageous because of the LTE economies of scale and it may enable tighter integration between communications with the network infrastructure (V2I) and V2P and V2V communications, as compared to using a dedicated V2x technology.

There are many ongoing and/or recent research projects and field tests of connected vehicles in various countries or regions, including projects that are based on the use of existing cellular infrastructure.

V2x communications may carry both non-safety and safety information, where each of the applications and services may be associated with specific

requirements sets, e.g., in terms of latency, reliability, capacity, etc. From the application point of view, V2x includes the types of communication/services outlined below, see also Fig. 1 which illustrates some different types of V2x communication, namely V2V, V2I, V2P and V2N. V2V (vehicle to vehicle): This type comprises communication between wireless devices or UEs in vehicles using V2V applications and is predominantly broadcast- based. V2V may be realized by either direct communication between the devices in the respective vehicles, or via infrastructure such as a cellular network. An example of V2V communication is the transmission of a cooperative awareness message (CAM) with vehicle status information (such as position, direction, and speed) transmitted to other vehicles in the proximity repeatedly (every 100ms-1 s). Another example is the transmission of a decentralized environmental notification message (DENM), which is an event-triggered message to alert vehicles. These two examples are taken from the Intelligent Transport Systems (ITS) specification of V2x applications defined by the European Telecommunications Standards Institute (ETSI), which also specifies the conditions under which the messages are generated. Some characteristics of V2V applications include the tight requirements on latency that can vary from 20ms (for pre-crash warning messages) to 100ms for other road safety services.

V2I (vehicle to infrastructure): This type comprises communication between vehicles and a Roadside Unit (RSU).The RSU is a stationary transportation infrastructure entity which communicates with vehicles in its proximity. An example of V2I is transmission of speed notifications from the RSU to vehicles, as well as queue information, collision risk alerts, curve speed warnings. Due to the safety related nature of V2I, delay requirements are similar to V2V requirements. A vehicle device may in this case communicate with devices residing in suitable infrastructure parts such as a stoplight as shown in Fig. 1.

V2P (vehicle to pedestrian): This type comprises communication between vehicles and vulnerable road users, such as pedestrians, using V2P applications. V2P typically takes place between distinct vehicles and pedestrians either directly or via infrastructure such as cellular network.

V2N (vehicle to network): This type comprises communication between a vehicle and a centralized application server or an ITS Traffic Management Center, both using V2N applications, via infrastructure such as a cellular network. Some non- limiting practical examples include a bad road condition warning sent to all vehicles currently located in a specific wide area, or communication for traffic flow optimization in which the V2N application suggests speeds to vehicles and coordinates traffic lights. Therefore, V2N messages are supposed to be controlled by a centralized entity such as the Traffic Management Center and provisioned to vehicles in a large geographical area, rather than in a small limited area. Additionally, unlike V2V/V2I, latency requirements are more relaxed in V2N because it is not meant to be used for non-safety purposes, e.g. a latency requirement of one second is typically considered.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues discussed herein. It is possible to achieve this object and others by using a transmitting node, a receiving User Equipment, UE, and methods therein, as defined in the attached independent claims.

According to one aspect, a method is performed by a transmitting node for enabling or supporting wireless communication with one or more receiving User Equipments, UEs. In this method, the transmitting node creates a Protocol Data Unit, PDU, with multiple components, and arranges said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU. The transmitting node then transmits the PDU with the arranged

components to the one or more receiving UEs.

According to another aspect, a transmitting node is arranged to enable or support wireless communication with one or more receiving UEs. The transmitting node is configured to create a PDU with multiple components, and to arrange said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU. The transmitting node is further configured to transmit the PDU with the arranged components to the one or more receiving UEs.

According to another aspect, a method is performed by a receiving UE for wireless communication with a transmitting node. In this method, the receiving UE receives a PDU with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature, such that the receiving UE is able to decode at least some components of the received PDU. Upon receiving the PDU, the receiving UE processes one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends according to said arranged components. The receiving UE further discards any component in the received PDU associated with a release, version and/or feature that the receiving UE does not comprehend.

According to another aspect, a receiving UE is arranged for wireless

communication with a transmitting node. The receiving UE is configured to receive a PDU with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature. The receiving UE is also configured to process one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends, and to discard any component in the PDU associated with a release, version and/or feature that the receiving UE does not comprehend.

When using one or more of the above methods and units, it is an advantage that the receiving UE is able to decode as many comprehended components as possible in the PDU, even all the comprehensible components that are included in the PDU. As a result, it can be avoided that one or more components that the receiving UE would comprehend will not be decoded by the UE and thereby wasted.

The above methods, transmitting node and UE may be configured and

implemented according to different optional embodiments to ensure the above advantages and/or to accomplish further features and benefits, to be described below.

A computer program is also provided comprising instructions which, when executed on at least one processor in either of the above transmitting node and UE, cause the at least one processor to carry out either of the methods described above. A carrier is also provided which contains the above computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium. It should be noted that the above processor may also be referred to as a processing circuitry which is basically a synonym for processor. Throughout this description, the term processor could thus be substituted by“processing circuitry”. Brief description of drawings

The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

Fig. 1 illustrates wireless communication between a UE and some different types of opposite entities, where the embodiments herein may be employed.

Fig. 2 illustrates an example of how a Medium Access Control (MAC) PDU can be structured with a MAC header and MAC payload including MAC control elements and MAC Service Data Units, SDUs.

Fig. 3 illustrates another example of how a MAC PDU can be structured with a MAC header and MAC payload including MAC SDUs.

Figs 4A and 4B illustrate examples of how subheaders in the MAC header of Fig.

3 may be structured in more detail.

Fig. 5 illustrates a possible arrangement of components in a PDU so that a receiving UE is able to decode those components in the PDU that the UE comprehends, according to some example embodiments.

Fig. 6 is a signaling diagram illustrating an example of how a transmitting node and a receiving UE may operate when communicating a PDU from the transmitting node to the receiving UE, according to further example embodiments.

Fig. 7 is a flow chart illustrating a procedure in a transmitting node, according to further example embodiments.

Fig. 8A is a flow chart illustrating a procedure in a receiving UE, according to further example embodiments.

Figs 8B-8C and 8D illustrate a comparison of how a received PDU is handled by a receiving UE when conventional procedures are used and when the solution is used, respectively. Fig. 9 is a block diagram illustrating how a transmitting node and a UE may be structured, according to further example embodiments.

Figs 10-15 illustrate further scenarios, structures and procedures that may be employed when the solution is used, according to further possible embodiments. Detailed Description

The embodiments and examples described herein may be used in a procedure for communicating a Protocol Data Unit, PDU, from a transmitting node to one or more receiving UEs. The transmitting node may be another UE or a network node and the PDU may be a Medium Access Control, MAC, PDU. First, some common definitions and existing procedures used for communicating PDUs, particularly MAC PDUs, will be described.

Sidelink Operations

As previously mentioned, Sidelink transmissions, also known as D2D or ProSe, over the so-called PC5 interface in cellular spectrum have been standardized in 3GPP since Rel-12. In 3GPP Rel-12, two different transmission modes have been specified for Radio Resource Control (RCC) defined by 3GPP. In one mode (mode-1 ), a UE in RRC_CONNECTED mode requests D2D resources and the eNB grants them via the Physical Downlink Control Channel, PDCCFI (DCI5) or via dedicated signalling. In another mode (mode-2), a UE autonomously selects resources for transmission from a pool of available resources that the eNB provides in broadcast via System Information Block (SIB) signalling for

transmissions on carriers in cells other than the Primary Cell denoted PCell, or via dedicated signaling for transmission on carriers in the PCell. Therefore, unlike the first operation mode, the second operation mode can be performed also by UEs in RRCJDLE and in some cases even by UEs out of coverage.

In Rel.14, the usage of sidelink is extended to the V2x domain. The original design of the sidelink physical layer in Rel.12 targeted a scenario with a small number of UEs competing for the same physical resources in the spectrum, to carry voice packet for traffic in the service called Mission Critical Push To Talk, MCPTT, and assumed low UE mobility. On the other hand, in V2x the sidelink should be able to cope with higher load scenario (i.e. , hundreds of cars potentially contending for physical resources), to carry time/event triggered V2x messages such as CAM, Decentralized Environmental Notification Message (DENM), and with high UE mobility. For such reasons, 3GPP has discussed possible enhancements to the sidelink physical layer.

A first enhancement that has been specified in Rel.14 is the introduction of a new transmission mode, i.e. mode-3, which resembles mode-1 in the sense that it is the eNB that explicitly assigns sidelink resources to the UE. However, unlike mode-1 , the eNB has the possibility to configure the sidelink resources semi- persistently in a SPS-like fashion where SPS denotes Semi Persistent Scheduling, i.e. the eNB assigns a sidelink grant for periodic transmissions on a certain frequency resource.

A second enhancement is the introduction of the so-called channel sensing and sensing-aware UE autonomous resource allocation, which corresponds to mode-4 transmission mode. Unlike random resource selection which is the base for Rel.12 and Rel.13 ProSe communications, in V2V (Rel-14) UEs are expected to continuously sense the channel and search for resources in the different part of the spectrum that are less interfered. Such channel sensing has the objective to limit collisions between UEs.

Two types of channel sensing have been considered in 3GPP:

1. Sensing based on received power. A UE measures the received energy on specific radio resources:

For example, based on these measurements, the UE may decide whether the radio resources are considered to be in use by some other UE (i.e.,

‘busy’) or not (i.e.,‘idle’).

For example, the UE may use the measurements to estimate whether the transmitter is far away (e.g., if the signal is weak) or nearby (e.g., if the signal is strong). 2. Sensing based on packet contents. A UE receives a packet and decodes it. Based on the information extracted from the packet, the UE may obtain some knowledge about the utilization of radio resources:

For example, by reading a scheduling assignment (SA) packet, a UE may know in which radio resources to expect data transmissions, and the priority level of the transmitter.

For example, by reading a data packet, a UE may know the position of the transmitter, the ID of transmitter, the type of transmitter, etc.

Although in mode-4, the UE autonomously selects the transmission resources on the basis of the sensing results, it is still possible for the eNB to signal some sets of the values that the UE is allowed to use for certain transmission parameters.

For example, for the number of Physical Resource Blocks (PRBs) used by a UE for a transmission the eNB may specify a minimum and maximum value i.e. , the UE is not allowed to use less than X PRBs or more than Y PRBs for the

transmission; whether the UE is allowed to transmit or not; the maximum and minimum Modulation and Coding Scheme (MCS) the UE can use, the

minimum/maximum transmission power; etc. In other words, the eNB can restrict the set of values that the UE can select for certain transmission parameters. Such sets/restrictions (on the transmission parameters) may be configured differently by the network for different UE conditions e.g. depending on the UE speed or channel congestion status. In addition to configuration by the eNB (or a network node in general), the sets/restrictions may also be part of a pre-configuration. Pre- configuration may be used as an alternative or as a complement to configuration by the eNB. Sidelink Quality of Service, QoS

Each packet to be transmitted over the PC5 interface is marked by the application layer to a specific packet tag, called ProSe Per Packet Priority, PPPP. Each PPPP represent a priority assigned by the application layer to a given sidelink packet. In particular, each PPPP can assume values from 1 to 8, where 1 represents the highest priority PPPP and 8 the lowest priority.

Depending on the PPPP assigned by application layers, different RAN procedures are applied. For example, for different PPPPs, different transmission parameters (e.g. MCS, transmitting power, number of PRBs, etc.) should be applied by the

UE, according to network configuration. The PPPP may also be used to determine whether a certain pool, or a certain carrier could be used depending on

interference/congestion situation experienced in that pool. In this way, a sort of admission control procedure based on the PPPP can be performed, so that for example higher-priority PPPP should be transmitted in lowest congested carriers/pool to increase the probability of correct reception.

In the MAC layer, the PPPP are mapped to the Logical Channel Identities, LCIDs, by the UE for logical channel prioritization when building a MAC PDU. The PPPP are also mapped to different LCGs, according to network configuration, and used in the Sidelink Buffer Status Report (BSR), so that the eNB can provide proper sidelink grant when scheduling the UE.

A so-called Uu QoS framework associates to each QoS Class Identifier (QCI), different performance requirements such as the data rate in terms of Guaranteed Bit Rate (GBR), or non-GBR, the packet delay budget, the reliability (i.e. the packet error rate (PER)). Unlike the Uu QoS framework, at the moment (up to Rel.14), no performance requirement, other than the PPPP is associated to a sidelink packet.

Each of this new QoS profiles may be represented at MAC layer with different LCIDs and different MAC procedures may be applicable to different LCIDs depending on the traffic characteristics. For example, in Release 15, 3GPP has decided to introduce packet duplication for those services which demands higher reliability. In particular, dedicated LCIDs are associated to duplicates so that the MAC receiver can distinguish duplicate packets from the original ones.

MAC PDU The MAC protocol is, in terms of a protocol stack, the layer-2 protocol immediately above the physical layer. The MAC PDU contains the information the transmitter sends to the receiver. It includes a control part denoted MAC Control Element (CE) and a data part denoted MAC Service Data Unit (SDU). The control part contains information typically related to the operation of MAC and the data part contains information from higher layer protocols.

The MAC PDU is described in section 6 of 3GPP TS 36.321 but can briefly be described as follows. In Fig. 2, which corresponds to Figure 6.1.2-3 from 36.321 v15.1.0 and illustrates a MAC PDU, it can be seen that the MAC PDU is comprised of a header and payload, referred to as the MAC header and MAC payload, respectively. The header further comprises a set of subheaders, as indicated by dashed lines to illustrate the MAC header in more detail. The various terms R, F2, E, LCID, F and L refer to different fields of information in the subheaders which are not necessary to describe as such in any detail to understand how a MAC PDU can be generally structured. It is sufficient to note that each subheader corresponds to, i.e. is associated with, either a particular MAC CE, in this example denoted MAC Control element 1 and 2, or a particular MAC SDU. One part of the subheader indicates the type of subheader (described by the LCID field) and the size of the corresponding control element or SDU (typically descried by the L-field).

The LCID values which describe the type of subheader, control element, and SDU are listed in 36.321. Several of the values are reserved. This means that their function has not been standardized. When a new MAC CE (or MAC SDU type) is standardized, one of the reserved LCID values are taken into use to denote the new MAC CE (or MAC SDU type). A UE supporting a certain Release of the MAC Protocol can support all LCID values up to and including that release, but not LCID values of future releases of the protocol.

If a MAC PDU, which contains a MAC CE standardized in this release of the MAC protocol, is sent to a UE of an older release, the receiving UE cannot correctly decode or parse the MAC PDU as it does not know the size of the MAC subheader. When this happens, the receiving UE will discard the complete MAC PDU.

For the sidelink, the MAC PDU structure is illustrated in Fig. 3 with MAC SDUs and a MAC header comprising a so-called SL-SCH subheader and multiple so- called R/R/E/LCID/F/L subheaders. Each R/R/E/LCID/F/L subheader has 7-bits or 15-bits of information in the L-field and the so-called SL-SCFI subheader contains information related to the source and destination layer-2 address. Fig. 4A

illustrates how the R/R/E/LCID/F/L subheader may be structured with information bits arranged in two octets denoted Oct 1 and Oct 2 where the L-field has 7-bits of information located in Oct 2. Fig. 4B illustrates the R/R/E/LCID/F/L subheader with information bits arranged in three octets denoted Oct 1 , Oct 2 and Oct 3 where the L-field has 15-bits of information located across Oct 2 and Oct 3.

Some problems that may occur when existing solutions for communication of a PDU are used, will now be explained.

In unicast operations where a transmitting node transmits a PDU to a particular targeted receiving UE, the transmitter typically knows the capabilities of the receiver, for example which LCID values it supports, and can refrain from using LCID values from later releases in the PDU that are beyond the UEs capabilities. Thereby, the receiving UE is able to comprehend and decode all components in the received PDU. However, in broadcast operations with multiple potential receivers it might not be possible for the transmitter to adapt the PDU to the capabilities of all the receivers. The transmitter need not even know which receivers will receive the PDU and how many there are. During these

circumstances, the receiver may not comprehend all components in the received PDU and will drop and discard the received PDU, as described earlier.

The above procedure of discarding the PDU altogether if something therein is not comprehended is particularly bad if the same MAC PDU contains multiple subheaders related to the MAC SDUs multiplexed in this MAC PDU. Such MAC subheaders may contain different fields, some of which are related to fields which the receiving UE already knows and thus comprehends, e.g. the LCID values specified up to the UE release, while some other MAC subheaders may contain fields which this UE does not know or comprehend, e.g. the LCID values specified in a later release. If the above case occurs, the UE normally discards the whole MAC PDU even though some of the MAC SDUs contained in this MAC PDU are related to MAC subheaders that the UE could comprehend and decode.

The embodiments and examples described below enable procedures that allow a transmitting UE or network node to arrange the MAC PDU content in a way such that a receiving UE will be able to decode at least some components of the MAC PDU. A component may be a MAC SDU or a MAC control element. In one example, the components may be arranged in a way so that the component related to a certain release contained in the MAC PDU can be correctly decoded by the receiving UE of the same release, irrespective of other MAC SDUs possibly multiplexed in the same MAC PDU.

The proposed solution may thus limit the amount of MAC SDUs that are

discarded, when the MAC PDU contains MAC subheaders fields which are unknown (i.e. reserved/invalid values) from the receiving UE perspective.

Some embodiments, examples and details of how a PDU can be arranged and communicated, will now be described.

It will sometimes be said herein that a component of a MAC PDU is associated with a certain release/version. This may include for example that a field in a component has been defined in a certain release/version. For example, if a field F1 in one component is defined in a release/version 13 while a field F2 in another component is defined in a release/version 15, then F1 will be considered to be associated with release/version 13 and F2 will be considered to be associated with release/version 15.

Another possibility is that a component is considered associated with a certain release/version if a field associated with the component (i.e. either in the subheader of the component or in the MAC SDU/control element) has a value defined in the certain release/version. For example, if a field F can take a value V1 which is defined in a release/version 13 and can also take a value V2 which is defined in a release/version 15, then the value V1 will be considered to be associated with release/version 13 and the value V2 will be considered to be associated with release/version 15.

It will sometimes also be mentioned that a component is associated with a certain feature if the component is defined for and/or used for a certain feature. It will later be explained that the transmitting UE may place a component in a late part of the MAC PDU if it is associated with a feature which is optional, while if a component is associated with a mandatory feature this component may be placed earlier.

A component may be a MAC SDU which may contain data received from a higher layer, or a MAC CE which may contain control data generated by the MAC entity itself.

It should be noted that the MAC PDU is typically comprised of one header-region and one data-region and each component has one subheader in the header- region and may have one component in the data-region (note that some components only have a subheader part). When it is said herein that a first component is placed before second component, it means that the first subheader is placed before the second subheader in the header-region of the MAC PDU, while in the data-region the first data-part is placed before the data-part of the second component. Consequently, this would not mean that the data-part of the first component is placed before the subheader-part of the second component. An example of how the above arrangement of components may be applied in a MAC PDU is illustrated in Fig. 5 where mappings between respective subheader components and corresponding data-part components are indicated by two-way arrows.

Some examples of how a transmitting node may arrange components in a PDU to be transmitted to a receiving UE, will now be described. In the following, the terms “arrange”,“place” and“allocate” are used interchangeably as synonyms to indicate basically how components are positioned in a PDU. It should be noted that even though these examples refer to a transmitting UE as a transmitting node, the described arrangements of components are not limited thereto and the PDU may be transmitted by any transmitting node. Operations that may be performed by a transmitting UE for arranging components in a PDU and by a receiving UE for handling the received PDU, respectively, are thus described below.

Transmitting UE operations

In one embodiment, a transmitting UE may arrange or“group” the MAC

subheaders depending on the release in which the fields contained therein have been specified. For example, the transmitting UE may allocate first in the MAC PDU the subheaders that are related to older releases. In another example, the transmitting UE may allocate first in the MAC PDU the MAC subheaders that are related to newer releases. Which one of the two examples is used depends on how the receiving UE decodes the MAC PDU, i.e. if the receiving UE decodes the MAC PDU starting from the first MAC subheader, the transmitting UE shall allocate the MAC subheaders starting from the fields that were specified in older releases, while if the receiving UE decodes the MAC PDU starting from the last MAC subheader, the transmitting UE shall allocate the MAC subheaders starting from the fields that were specified in newer releases.

In one example procedure, a transmitting UE or node may place in the MAC header a MAC subheader which is mandatory before/earlier than a MAC subheader which is optional. Correspondingly, a MAC Service Data Unit (SDU) or a MAC Control Element (CE), either associated with the mandatory MAC subheader, will in this case be placed in the MAC payload before/earlier than a MAC SDU/CE associated with the optional MAC subheader.

In another example procedure, a transmitting UE may apply either of the above mentioned ways of arranging, allocating and placing MAC subheaders, CEs and SDUs independently for the MAC CE, and for the MAC SDUs intended to different destination IDs, i.e. associated to different services. For example, the transmitting UE may first allocate all the MAC CEs starting from the associated MAC

subheaders related to older releases, then the UE may allocate all the MAC SDUs intended to a certain destination X, starting from the associated MAC subheaders related to older releases, then the UE may allocate all the MAC SDUs intended to a certain destination Y starting from the associated MAC subheaders related to older releases, and so on for the destination IDs. In another alternative, the UE may first allocate the MAC subheaders related to destination X and Y depending on when the SL-SCH header of X and Y have been specified. For example, first to destination X if the SL-SCH header of the MAC SDU is associated to a value known by older UE of older releases, and then destination Y. In another procedure, the MAC CE may be allocated at the end of the MAC PDU

arrangement. A possible arrangement of components in a PDU to enable a receiving UE to decode those components in the PDU that the UE comprehends, is illustrated in Fig. 5, where components of older releases are allocated before/earlier than components of newer releases within the respective MAC header and MAC payload. In more detail, this figure illustrates that components of Release 14“Rel. 14” are allocated at the beginning in the MAC header and in the respective MAC

CE and MAC SDU, followed by components of Release 15“Rel. 15” and then components of Release 16“Rel. 16”, where lower numbered releases are thus older than higher numbered releases.

Receiving UE operations The receiving UE may process the MAC PDU starting from the beginning of the received MAC PDU, and if it finds a MAC subheader which is unknown it stops decoding the MAC PDU, ignores the other MAC SDUs/control elements contained in the MAC PDU not yet processed, and passes to upper layers the MAC SDUs already correctly received or processed the MAC control elements associated with those MAC subheader which the UE is able to comprehend.

The start of the MAC PDU may be defined as the most significant bits. Another definition may be starting from the end of the bit-sequence containing the MAC header (which may be the same as the most significant bits). The MAC PDU comprises a set of MAC subheaders and each such subheader is associated with a MAC SDU or a MAC control element. This arrangement implies that the receiving UE will process the first MAC subheader and the associated MAC PDU/control element, and then the UE will process the second MAC subheader and the MAC PDU/control element associated with that subheader, and so forth.

In one alternative of this example, the receiving UE may first process all MAC subheaders in the MAC PDU, if or until the MAC entity finds a MAC subheader which the MAC entity does not comprehend (where comprehend may mean not able to understand a certain component which may imply that a field is set to a (for this MAC entity) reserved value, or a (for this MAC entity) reserved bit is set to a certain value, e.g. set to 1. And when the receiving UE has processed all MAC subheaders which it comprehended, the UE will process the associated MAC SDU(s)/control elements.

It should be noted that while it is said above that the receiving UE processes all subheaders before starting processing the associated SDUs/control element, but in an implementation the UE may perform this processing in parallel. This means that in an example where the received PDU comprises, say, five subheaders denoted A-E, the receiving UE may process subheaders A, B and C out of subheaders A to E, and at that point the UE has processed MAC SDU/control element A.

When it is said above that a component in the MAC PDU is comprehended or not, it may imply that the receiving UE is not capable of understanding that component, e.g. the UE does not support associated functionality. Another alternative is that the receiving UE considers something not comprehended if the UE is not configured with associated functionality which is needed/relevant for

comprehend/apply the associated functionality.

It has been described above how the receiving UE may decode the MAC PDU from front to back of the PDU, which can be used if the transmitter has placed older components in the beginning of the MAC PDU such as in Fig. 5. However it would also be possible that the receiving UE decodes the MAC PDU from back to front of the PDU, which can be used if the transmitter has placed newer

components in the beginning of the MAC PDU.

A communication scenario where the solution is employed is illustrated in Fig. 6 involving a transmitting node 600 and a receiving UE 602, which may

communicate with each other over a wireless radio link 604. Fig. 6 is described below together with Figs 7 and 8A. The transmitting node 600 may be another UE or a network node of a wireless network.

An example of how the solution may be employed in terms of actions performed by a transmitting node such as the transmitting node 600, is illustrated by the flow chart in Fig. 7 which will now be described with further reference to Fig. 6. Fig. 7 thus illustrates a procedure in the transmitting node 600 for enabling or supporting wireless communication with one or more receiving UEs such as the receiving UE 602. A first action 700 illustrates that the transmitting node 600 creates a Protocol Data Unit, PDU, with multiple components, as also shown in action 6:1 of Fig. 6. In another action 702, the transmitting node 600 further arranges said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some

components of the PDU, as also indicated in action 6:1 of Fig. 6. In another action 704, the transmitting node 600 transmits the PDU with the arranged components to the one or more receiving UEs, as also shown in action 6:2 of Fig. 6.

Some further examples of embodiments that may be employed in the above procedure in Fig. 7 will now be described. In one example embodiment, the PDU may be a Medium Access Control, MAC, PDU, as in several of the examples described herein. In some further example embodiments, the components may include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features. In further example embodiments, a component in the PDU may be a MAC Service Data Unit, SDU or a MAC Control Element, CE.

In another example embodiment, in case the PDU is a MAC PDU, the components in the MAC PDU may be arranged in action 702 by arranging MAC subheaders depending on the release in which the fields contained therein have been specified. In that case, some further example embodiments of how the MAC subheaders could be arranged in the MAC PDU may be as follows. If the receiving UE(s) is/are expected to decode the MAC PDU starting from the first MAC subheader, the MAC subheaders may be allocated in the MAC PDU starting from the fields that were specified in older releases. If the receiving UE(s) is/are expected to decode the MAC PDU starting from the last MAC subheader, the MAC subheaders may be allocated in the MAC PDU starting from the fields that were specified in newer releases.

It should be noted that arranging components in the PDU depending on

release/version/feature may generally comprise placing subheaders and data units from an earlier release/version/feature before subheaders and data units from a later release/version/feature, in the case when the receiving UE is expected to read the components from beginning to end of the PDU.

In another example embodiment, a component may be placed in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature this component can in this case be placed earlier in the MAC PDU.

Another example of how the solution may be employed in terms of actions performed by a receiving UE such as the UE 602, is further illustrated by the flow chart in Fig. 8A which will now be described likewise with further reference to Fig.

6. It should be noted that the procedure of Fig. 8A may follow immediately after the procedure of Fig. 7. Fig. 8A thus illustrates a procedure in the receiving UE 602 for wireless communication with a transmitting node 600. A first action 800 illustrates that the receiving UE 602 receives a Protocol Data Unit, PDU, with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature, such that the receiving UE is able to decode at least some components of the PDU. This action corresponds to action 6:2 of Fig. 6.

A further action 802 illustrates that the receiving UE 602 processes one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends according to the arranged components, as also shown in action 6:3 of Fig. 6. In another action 804, the receiving UE 602 discards any component in the PDU associated with a release, version and/or feature that the receiving UE does not comprehend, as also indicated in action 6:3 of Fig. 6.

In either of the procedures of Figs 7 and 8, the PDU may be a Medium Access Control, MAC, PDU. Further, the components in the PDU may include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features. Also, a component in the PDU may be a MAC Service Data Unit, SDU or a MAC Control Element, CE.

Some further examples of embodiments that may be employed in the above procedure in Fig. 8A will now be described. In one example embodiment, the PDU may be a MAC PDU, as in the procedure of Fig. 7 and in several of the examples described herein. In some further example embodiments, the components may include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features. In further example embodiments, a component in the PDU may be a MAC SDU or a MAC CE.

In another example embodiment, in case the PDU is a MAC PDU, said

components may be arranged in the MAC PDU so that MAC subheaders are arranged depending on the release in which the fields contained therein have been specified. In that case, some further example embodiments of how the receiving UE could decode the MAC PDU may be as follows. One alternative is that the receiving UE could decode the MAC PDU starting from the first MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in older releases. Another alternative is that the receiving UE could decode the MAC PDU starting from the last MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in newer releases.

In further example embodiments, a component could be placed in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature this component could be placed earlier in the MAC PDU.

In another example embodiment, the receiving UE may process the MAC PDU starting from the beginning of the received MAC PDU, and if the UE finds a MAC subheader which is unknown the receiving UE may stop decoding the MAC PDU and ignore the not yet processed MAC SDUs/control elements contained in the MAC PDU.

In another example embodiment, when the MAC PDU comprises a set of MAC subheaders where each MAC subheader is associated with a MAC SDU or a MAC control element, the receiving UE may process the first MAC subheader and the MAC PDU or control element associated with the first MAC subheader, and then the UE may process the second MAC subheader and the MAC PDU or control element associated with the second MAC subheader, and so forth.

In another alternative embodiment, when the receiving UE has processed all MAC subheaders which it comprehended, the receiving UE may process the MAC SDU(s)/control elements associated with the processed MAC subheaders. Some examples of how a received PDU would be handled by a receiving UE when the PDU is arranged in a conventional manner and when the PDU is arranged according to the embodiments herein, respectively, will now be described with reference to Figs 8B-8D. The PDUs are shown to comprise the components C1 - C7 related to different releases, versions and/or features, although in practice a PDU may comprise any number of such components. In these figures,

components that are comprehended and can be decoded by the receiving UE are depicted as dotted boxes while components that are not comprehended and cannot be decoded by the receiving UE are depicted as white boxes. The components in the PDUs shown in Figs 8B and 8C are conventionally arranged in the same manner while the PDUs shown in Fig 8D are arranged according to the embodiments herein. When receiving the PDU in these examples, the receiving UE will try to decode the components from back to front starting from the beginning, i.e. to the left, of the PDU.

The PDUs shown in Figs 8B and 8C comprise components that are thus conventionally arranged in the same manner, i.e. in the same order. The receiving UE comprehends components C1 , C2, C5 and C6 as they are of releases, versions and/or features within the UEs capabilities. Flowever, the receiving UE does not comprehend components C3, C4 and C7 which may be of later releases, versions and/or features than C1 , C2, C5 and C6 and lying beyond the UEs capabilities.

In Fig. 8A, the conventionally arranged PDU is transmitted from the transmitting node in a broadcast fashion and the receiving UE is operable to handle the PDU as follows. When receiving the PDU, the UE thus tries to read and decode the components starting from the left of the PDU. The UE is able to decode the first two components C1 , C2 which are comprehended, but when coming to

component C3 it is not comprehended and the UE is in this case operable to stop reading the components and to disregard all remaining components after C2, i.e. components C3-C7, as stipulated in broadcast communications. This means that the receiving UE can use only the two decoded components C1 and C2 while components C5 and C6 will not be used even though they were comprehensible to the UE.

In Fig. 8B, the likewise conventionally arranged PDU is transmitted from the transmitting node in a sidelink fashion and the receiving UE is operable to handle the PDU as follows. When receiving the PDU, the UE will again try to read and decode the components starting from the left of the PDU and is thus able to decode the comprehended components C1 , C2. When coming to component C3 it is not comprehended and the UE is in this case operable to stop reading the components and discard the entire PDU including all components C1 -C7, as stipulated in sidelink communications. Thereby, no components will be used even though C1 , C2 and C5, C6 were comprehensible to the UE.

In Fig. 8C, the components in the PDU are arranged according to the

embodiments herein, that is depending on at least one of: 3GPP release, version and feature, such that the receiving UE will be able to decode at least some components of the PDU. This can be accomplished as follows. Components C1 , C2, C3 and C4 are of releases, versions and/or features within the UEs

capabilities and are therefore arranged in the beginning (left) of the PDU while the remaining components C5-C7 cannot be comprehended by the UE. As a result, the receiving UE is able to decode all the comprehended components C1 -C4 and when coming to component C5 it is not comprehended and the UE is in this case operable to stop reading the components and therefore disregards all remaining components after C4, i.e. components C5-C7. This means that the receiving UE can use the decoded components C1 -C4 while only components C5-C7 will be unused as they could not be comprehended by the UE anyway. In other words, if it finds a component C5 which is unknown the receiving UE will stop decoding the PDU and ignore the not yet processed components C5-C7 contained in the PDU.

When comparing the above three examples in Figs 8B-D, it is noted that the UE has decoded all components in the PDU that it comprehends in Fig. 8D and no comprehensible component will be wasted, while two and all four comprehensible components in the PDU will be wasted in Figs 8B and 8C, respectively.

The block diagram in Fig. 9 illustrates a detailed but non-limiting example of how a transmitting node 900 and a receiving UE 902, respectively, may be structured to bring about the above-described solution and embodiments thereof. In this figure, the transmitting node 900 and the receiving UE 902 may be configured to operate according to any of the examples and embodiments of employing the solution as described herein, where appropriate, e.g. in the manner described above for the transmitting node 600 and the receiving UE 602 of Fig. 6. Each of the transmitting node 900 and the receiving UE 902 is shown to comprise a processor“P”, a memory“M” and a communication circuit“C” with suitable equipment for transmitting and receiving radio signals in the manner described herein.

The communication circuit C in each of the transmitting node 900 and the receiving UE 902 thus comprises equipment configured for communication with each other using a suitable protocol for the communication depending on the implementation. The solution is however not limited to any specific types of radio signals or protocols.

The transmitting node 900 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow chart in Fig. 7 and as follows. Further, the receiving UE 902 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow chart in Fig. 8A and as follows.

The transmitting node 900 is arranged to enable or support wireless

communication with one or more receiving User Equipments, UEs, such as the receiving UE 902. The transmitting node 900 is configured to create a Protocol Data Unit, PDU, with multiple components. This operation may be performed by a creating module 900A in the transmitting node 900, as also illustrated in action 700. The transmitting node 900 is also configured to arrange said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU. This operation of arranging components may be performed by an arranging module 900B in the transmitting node 900, as also illustrated in action 702. The transmitting node 900 is also configured to transmit the PDU with the arranged components to the one or more receiving UEs, which may be performed by a transmitting module 900C in the transmitting node 900, as also illustrated in action 704. The receiving UE 902 is arranged for wireless communication with a transmitting node 900. The receiving UE 902 is configured to receive a Protocol Data Unit, PDU, with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature, such that the receiving UE is able to decode at least some components of the PDU. This operation may be performed by a receiving module 902A in the receiving UE 902, as also illustrated in action 800.

The receiving UE 902 is further configured to process one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends according to said arranged components. This operation may be performed by a processing module 902B in the receiving UE 902, as also illustrated in action 802. The receiving UE 902 is also configured to discard any component in the PDU associated with a release, version and/or feature that the receiving UE does not comprehend. This operation may be performed by a discarding module 902C in the receiving UE 902, as also illustrated in action 804.

It should be noted that Fig. 9 illustrates various functional modules in the transmitting node 900 and the receiving UE 902, respectively, and the skilled person is able to implement these functional modules in practice using suitable software and hardware equipment. Thus, the solution is generally not limited to the shown structures of the transmitting node 900 and the receiving UE 902, and the functional modules therein may be configured to operate according to any of the features, examples and embodiments described in this disclosure, where appropriate.

The functional modules 900A-C and 902A-C described above may be

implemented in the transmitting node 900 and the receiving UE 902, respectively, by means of program modules of a respective computer program comprising code means which, when run by the processor P causes the transmitting node 900 and the receiving UE 902 to perform the above-described actions and procedures.

Each processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, each processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). Each processor P may also comprise a storage for caching purposes.

Each computer program may be carried by a computer program product in each of the transmitting node 900 and the receiving UE 902 in the form of a memory having a computer readable medium and being connected to the processor P. The computer program product or memory M in each of the transmitting node 900 and the receiving UE 902 thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory M in each node may be a flash memory, a

Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the respective transmitting node 900 and receiving UE 902.

The solution described herein may be implemented in each of the transmitting node 900 and the receiving UE 902 by a computer program comprising

instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the above embodiments and examples, where appropriate. The solution may also be implemented at each of the transmitting node 900 and the receiving UE 902 in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

While the solution has been described with reference to some exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms“transmitting node”,“wireless device”,“PDU”,“component”, “subheader”,“release”,“version” and“feature” have been used throughout this disclosure, although any other corresponding entities, functions, and/or parameters could also be used having the characteristics described herein. The solution may be implemented according to the appended claims.

Some further extensions and variations where the above-described embodiments and examples could be employed, will now be described.

With reference to Fig. 10, in accordance with an embodiment, a

communication system includes a telecommunication network 3210 e.g. a WLAN, such as a 3GPP-type cellular network, which comprises an access network 3211 , such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE) such as a Non-AP STA 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 such as a Non-AP STA in coverage area 3213a is wirelessly connectable to the

corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is

connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221 , 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Fig. 10 as a whole enables connectivity between one of the connected UEs 3291 , 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291 , 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink

communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 11. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig. 11 ) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig. 11 ) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field

programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field

programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331 , which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 11 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Fig. 10, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 11 and independently, the surrounding network topology may be that of Fig. 10.

In Fig. 11 , the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the efficiency in communication and thereby provide benefits such as better utilization of resources in the network.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the

measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311 , 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 11. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In a first action 3410 of the method, the host computer provides user data. In an optional subaction 3411 of the first action 3410, the host computer provides the user data by executing a host application. In a second action 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third action 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 11. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In a first action 3510 of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third action 3530, the UE receives the user data carried in the transmission.

Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 11. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section. In an optional first action 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second action 3620, the UE provides user data. In an optional subaction 3621 of the second action 3620, the UE provides the user data by executing a client application. In a further optional subaction 3611 of the first action 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction 3630, transmission of the user data to the host computer. In a fourth action 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 11. For simplicity of the present disclosure, only drawing references to Fig. 15 will be included in this section. In an optional first action 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second action 3720, the base station initiates transmission of the received user data to the host computer. In a third action 3730, the host computer receives the user data carried in the transmission initiated by the base station.

Claims

1. A method performed by a transmitting node (600) for enabling or supporting wireless communication with one or more receiving User Equipments, UEs (602), the method comprising: - creating (6:1 , 700) a Protocol Data Unit, PDU, with multiple components,

- arranging (6:1 , 702) said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU, and

- transmitting (6:2, 704) the PDU with the arranged components to the one or more receiving UEs.

2. A method according to claim 1 , wherein the PDU is a Medium Access Control, MAC, PDU.

3. A method according to claim 2, wherein the components include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features.

4. A method according to claim 2 or 3, wherein a component in the PDU is a MAC Service Data Unit, SDU or a MAC Control Element, CE.

5. A method according to any of claims 2-4, wherein arranging said components in the MAC PDU comprises arranging MAC subheaders depending on the release in which the fields contained therein have been specified.

6. A method according to claim 5, wherein if the receiving UE(s) decodes the MAC PDU starting from the first MAC subheader, the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in older releases, while if the receiving UE(s) decodes the MAC PDU starting from the last

MAC subheader, the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in newer releases.

7. A method according to any of claims 2-6, wherein a component is placed in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature this component is placed earlier in the MAC PDU.

8. A transmitting node (900) arranged to enable or support wireless communication with one or more receiving User Equipments, UEs (902), wherein the transmitting node is configured to:

- create (900A) a Protocol Data Unit, PDU, with multiple components,

- arrange (900B) said components in the PDU depending on at least one of: 3GPP release, version and feature, such that the one or more receiving UEs will be able to decode at least some components of the PDU, and

- transmit (900C) the PDU with the arranged components to the one or more receiving UEs.

9. A transmitting node (900) according to claim 8, wherein the PDU is a Medium Access Control, MAC, PDU.

10. A transmitting node (900) according to claim 9, wherein the components include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features.

11. A transmitting node (900) according to claim 9 or 10, wherein a component in the PDU is a MAC Service Data Unit, SDU or a MAC Control Element, CE.

12. A transmitting node (900) according to any of claims 9-11 , wherein the transmitting node is configured to arrange said components in the MAC PDU by arranging MAC subheaders depending on the release in which the fields contained therein have been specified.

13. A transmitting node (900) according to claim 12, wherein if the receiving UE(s) decodes the MAC PDU starting from the first MAC subheader, the transmitting node is configured to allocate the MAC subheaders in the MAC PDU starting from the fields that were specified in older releases, while if the receiving UE(s) decodes the MAC PDU starting from the last MAC subheader, the transmitting node is configured to allocate the MAC subheaders in the MAC PDU starting from the fields that were specified in newer releases.

14. A transmitting node (900) according to any of claims 9-13, wherein the transmitting node is configured to place a component in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature the transmitting node is configured to place this component earlier in the MAC PDU.

15. A method performed by a receiving User Equipment, UE (602) for wireless communication with a transmitting node (600), the method comprising: - receiving (6:2, 800) a Protocol Data Unit, PDU, with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature, such that the receiving UE is able to decode at least some components of the PDU,

- processing (6:3, 802) one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends according to said arranged components, and

- discarding (6:3, 804) any component in the PDU associated with a release, version and/or feature that the receiving UE does not comprehend.

16. A method according to claim 15, wherein the PDU is a Medium Access Control, MAC, PDU.

17. A method according to claim 16, wherein the components in the PDU include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features.

18. A method according to any of claims 16-17, wherein a component in the PDU is a MAC Service Data Unit, SDU or a MAC Control Element, CE.

19. A method according to any of claims 16-18, wherein said components are arranged in the MAC PDU so that MAC subheaders are arranged depending on the release in which the fields contained therein have been specified.

20. A method according claim 19, wherein the receiving UE decodes the MAC PDU starting from the first MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in older releases, or the receiving UE decodes the MAC PDU starting from the last MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in newer releases.

21. A method according to any of claims 16-20, wherein a component is placed in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature this component is placed earlier in the MAC PDU.

22. A method according to any of claims 16-21 , wherein the receiving UE processes the MAC PDU starting from the beginning of the received MAC PDU, and if it finds a MAC subheader which is unknown the receiving UE stops decoding the MAC PDU, and ignores the not yet processed MAC SDUs/control elements contained in the MAC PDU.

23. A method according to any of claims 16-22, wherein when the MAC PDU comprises a set of MAC subheaders where each MAC subheader is associated with a MAC SDU or a MAC control element, the receiving UE processes the first

MAC subheader and the MAC PDU or control element associated with the first MAC subheader, and then the UE processes the second MAC subheader and the MAC PDU or control element associated with the second MAC subheader, and so forth.

24. A method according to any of claims 16-22, wherein when the receiving UE has processed all MAC subheaders which it comprehended, the receiving UE will process the MAC SDU(s)/control elements associated with the processed MAC subheaders.

25. A receiving User Equipment, UE (902) arranged for wireless

communication with a transmitting node (600), wherein the receiving UE is configured to:

- receive (902A) a Protocol Data Unit, PDU, with multiple components which are arranged in the PDU depending on at least one of: 3GPP release, version and feature, such that the receiving UE is able to decode at least some components of the PDU,

- process (902B) one or more components in the PDU associated with a release, version and/or feature that the receiving UE comprehends according to said arranged components, and - discard (902C) any component in the PDU associated with a release, version and/or feature that the receiving UE does not comprehend.

26. A receiving UE (902) according to claim 25, wherein the PDU is a Medium Access Control, MAC, PDU.

27. A receiving UE (902) according to claim 26, wherein the components in the PDU include at least one of: a set of subheaders associated with specific releases, versions and/or features, and a set of data units associated with specific releases, versions and/or features.

28. A receiving UE (902) according to any of claims 26-27, wherein a component in the PDU is a MAC Service Data Unit, SDU or a MAC Control Element, CE.

29. A receiving UE (902) according to any of claims 26-28, wherein said components are arranged in the MAC PDU so that MAC subheaders are arranged depending on the release in which the fields contained therein have been specified.

30. A receiving UE (902) according claim 29, wherein the receiving UE is configured to decode the MAC PDU starting from the first MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in older releases, or to decode the MAC PDU starting from the last MAC subheader when the MAC subheaders are allocated in the MAC PDU starting from the fields that were specified in newer releases.

31. A receiving UE (902) according to any of claims 26-30, wherein a component is placed in a late part of the MAC PDU if it is associated with an optional feature, while if a component is associated with a mandatory feature this component is placed earlier in the MAC

32. A receiving UE (902) according to any of claims 26-31 , wherein the receiving UE is configured to process the MAC PDU starting from the beginning of the received MAC PDU, and if it finds a MAC subheader which is unknown the receiving UE is configured to stop decoding the MAC PDU, and to ignore the not yet processed MAC SDUs/control elements contained in the MAC PDU.

33. A receiving UE (902) according to any of claims 26-32, wherein when the MAC PDU comprises a set of MAC subheaders where each MAC subheader is associated with a MAC SDU or a MAC control element, the receiving UE is configured to process the first MAC subheader and the MAC PDU or control element associated with the first MAC subheader, and then to process the second MAC subheader and the MAC PDU or control element associated with the second MAC subheader, and so forth.

34. A receiving UE (902) according to any of claims 26-32, wherein when the receiving UE has processed all MAC subheaders which it comprehended, the receiving UE is configured to process the MAC SDU(s)/control elements associated with the processed MAC subheaders.

35. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 -7 or the method according to any one of claims 15-24.

36. A carrier containing the computer program of claim 35, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.