WO2025098835A1

WO2025098835A1 - Erroneous packet management

Info

Publication number: WO2025098835A1
Application number: PCT/EP2024/080592
Authority: WO
Inventors: Saeed Reza KHOSRAVIRAD; Tze-Yang TUNG; Jinfeng DU
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2023-11-08
Filing date: 2024-10-29
Publication date: 2025-05-15
Anticipated expiration: 2026-05-08

Abstract

Certain examples of the present disclosure relate to an apparatus (10) comprising: means (11) for receiving configuration information (202) for enabling the apparatus to operate in an operational mode (203), wherein in the operational mode: based at least in part on a determination that at least a first packet (302) received at the apparatus has been erroneously decoded by the apparatus, at least a second packet (308) is generated wherein the at least second packet comprises information (306) from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient (310); and means (11) for operating the apparatus in the operational mode based at least in part on the configuration information.

Description

ERRONEOUS PACKET MANAGEMENT

TECHNOLOGICAL FIELD

Examples of the disclosure relate to management of erroneous packets, in particular an apparatus, a method, a system, and a computer program for managing erroneously decoded packets. Some examples, though without prejudice to the foregoing, relate to augmentation and transfer of erroneously decoded packets.

BACKGROUND

Conventional decoding systems and error detection mechanisms for the transmission of packets in a Radio Access Network are not always optimal. Typically, if a decoding error is detected following a decoding of a packet (for example if, after performing a channel decoding process on a received packet, a Cyclic Redundancy Check, CRC, fails), and the allowed number of retransmissions is reached within a latency budget (for example via a Hybrid Automatic Repeat Request, HARQ, or Automatic Repeat Request, ARQ, process) then the packet is discarded (for example by a Medium Access Control/Radio Link Control, MAC/RLC, layer of a Radio Access Network, RAN, receiver).

In some circumstances it can be desirable to improve the management of erroneously decoded packets. In some circumstances it can be desirable to seek to provide semantic/effective communication.

The listing or discussion of any prior-published document or any background in this specification should not necessarily be taken as an acknowledgement that the document or background is part of the state of the art or is common general knowledge. One or more aspects/examples of the present disclosure may or may not address one or more of the background issues.

BRIEF SUMMARY

According to various, but not necessarily all, examples of the disclosure there are provided examples as claimed in the appended claims. Any examples and features described in this specification that do not fall underthe scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

According to at least some examples of the disclosure there is provided an apparatus comprising: means for receiving configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and means for operating the apparatus in the operational mode based at least in part on the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a method comprising: receiving, at an apparatus, configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operating the apparatus in the operational mode based at least in part on the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a chipset comprising processing circuitry configured to perform the above-mentioned method.

According to various, but not necessarily all, examples of the disclosure there is provided a memory access device, module, circuitry, device and/or system comprising means for performing the above-mentioned method.

According to various, but not necessarily all, examples of the disclosure there is provided a computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform: receiving, at the apparatus, configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operating the apparatus in the operational mode based at least in part on the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided an apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operate the apparatus in the operational mode based at least in part on the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a non-transitory computer readable medium encoded with instructions that, when executed by at least one processor, causes at least the following to be performed: receive configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operate the apparatus in the operational mode based at least in part on the configuration information.

According to at least some examples of the disclosure there is provided an apparatus comprising: means for receiving a request, from an apparatus, to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; means for determining, based at least in part on the request, configuration information for configuring the apparatus to operate in the operational mode; and means for sending, to the apparatus, the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a method comprising: receiving, at a first apparatus from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determining, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform: receiving, from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determining, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided an apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receiving, from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determining, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information. According to various, but not necessarily all, examples of the disclosure there is provided a non-transitory computer readable medium encoded with instructions that, when executed by at least one processor, causes at least the following to be performed: receiving, at a first apparatus from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determining, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information.

According to various, but not necessarily all, examples of the disclosure there is provided a method of providing and/or manufacturing an apparatus and/or system as described herein.

According to various, but not necessarily all, examples of the disclosure there is provided a method of using an apparatus and/or system as described herein.

The following portion of this 'Brief Summary’ section describes various features that can be features of any of the examples described in the foregoing portion of the 'Brief Summary’ section mutatis mutandis. The description of a function should additionally be considered to also disclose any means suitable for performing that function, or any instructions stored in at least one memory that, when executed by at least one processor, cause an apparatus to perform that function.

In some but not necessarily all examples, the means for operating the apparatus in the operational mode based at least in part on the configuration information comprises: means for receiving the at least first packet; means for decoding the at least first packet; means for determining whether the at least first packet has been erroneously decoded; means for determining the information from the at least part of the erroneously decoded at least first packet; means for generating the at least second packet comprising the information from the at least part of the erroneously decoded at least first packet, wherein the generation of the at least second packet is based at least in part on determining that the at least first packet has been erroneously decoded; and means for transferring the at least second packet to the recipient.

In some but not necessarily all examples, determining whether the at least first packet has been erroneously decoded comprises at least one of the following: detecting an error in the decoded at least first packet; detecting an error in a channel decoding process performed on the at least first packet; detecting a failure of a Cyclic Redundancy Check, CRC; or detecting a latency for the at least first packet exceeding a threshold.

In some but not necessarily all examples, the information from the at least part of the erroneously decoded at least first packet comprises at least one of the following: one or more decoded symbols of the at least first packet; one or more hard decoded bits of the at least first packet; one or more soft coded bits indicative of one or more confidence levels of one or more hard decoded bits of the at least first packet; one or more Log Likelihood Ratio, LLR, values; one or more codewords derived from the erroneously decoded at least first packet; one or more of the most likely codewords based at least in part on soft coded bits associated with the erroneously decoded first packet; an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

In some but not necessarily all examples, the at least second packet further comprises at least one of the following: information indicative of a state of a channel via which the at least first packet was conveyed; information indicative of a decoding process via which the at least first packet was decoded.

In some but not necessarily all examples, the apparatus is at least one or the following: a User Equipment, UE; or a memory access device.

In some but not necessarily all examples, transferring the at least second packet to a recipient comprises at least one of the following: passing the at least second packet to an application layer; passing the second packet from a Medium Access Control layer of the apparatus to an application layer of the apparatus; bypassing one or more radio access network protocol stack layers; or transferring the at least second packet to an application residing on the apparatus.

In some but not necessarily all examples, the apparatus further comprises means for transmitting a request to operate in the operational mode.

In some but not necessarily all examples, the request comprises at least one of the following: an identifier of an application residing on the apparatus; or a request for a packet format of the at least second packet.

In some but not necessarily all examples, the configuration information comprises an indication of at least one of the following: an identifier of an application residing on the apparatus; or a packet format of the at least second packet.

In some but not necessarily all examples, the configuration information is based at least in part on the request.

In some but not necessarily all examples, the at least second packet has a packet format, and wherein the packet format is pre-determined between an application of the apparatus and a second apparatus that is a source of the at least first packet.

In some but not necessarily all examples, the packet format of the at least second packet indicates whether the at least second packet is to comprise at least one of the following: an indication for identifying the at least second packet as a packet that is generated, based at least in part on the determination that the at least first packet has been erroneously decoded; an indication for identifying the at least second packet as a packet that comprises information from at least a part of the erroneously decoded at least first packet; an indication that the at least first packet was erroneously decoded; one or more decoded symbols of the at least first packet; one or more hard coded bits of the at least first packet; one or more soft coded bits indicative of one or more confidence levels of one or more hard decoded bits of the at least first packet; one or more Log Likelihood Ratio, LLR, values; one or more codewords derived from the erroneously decoded at least first packet; one or more of the most likely codewords based at least in part on soft coded bits associated with the erroneously decoded first packet; an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

In some but not necessarily all examples, the configuration information comprises information for configuring the apparatus to bypass one or more layers of a radio access network stack.

In some but not necessarily all examples, wherein at least one of the following applies: the apparatus is a network node of a Radio Access Network; the recipient is a core node of a Radio Access Network; the recipient is a User Plane Function; or the recipient is a node of a second Radio Access Network. In some but not necessarily all examples, the apparatus further comprises means for requesting establishment of a link between the apparatus and a second apparatus that is a source of the at least first packet, wherein the link is configured such that, for one or more packets transmitted via the link, the apparatus operates in the operational mode.

In some but not necessarily all examples, the means for requesting establishment of the link comprises means for requesting at least one of the following: one or more layers of a radio access network stack be bypassed during the reception and/or transmission of one or more packets conveyed via a radio link; one or more layers above a Media Access Control, MAC, or Physical, PHY, layer be bypassed during a reception and/or transmission of one or more packets conveyed via a radio link; a modulation scheme be used for the transmission of one or more packets conveyed via a radio link; a modulation constellation be used for the transmission of one or more packets conveyed via a radio link; a coding scheme be used for the transmission of one or more packets conveyed via a radio link; or a code rate and/or type be used for the transmission of one or more packets conveyed via a radio link.

While the above examples of the disclosure and optional features are described separately, it is to be understood that their provision in all possible combinations and permutations is contained within the disclosure. It is to be understood that various examples of the disclosure can comprise any or all of the features described in respect of other examples of the disclosure, and vice versa. Also, it is to be appreciated that any one or more or all of the features, in any combination, may be implemented by/comprised in/performable by an apparatus, a method, and/or computer program instructions as desired, and as appropriate.

BRIEF DESCRIPTION OF THE DRAWINGS

Some examples will now be described with reference to the accompanying drawings in which:

FIG. 1 schematically illustrates an example of a radio telecommunications network suitable for use with an example of the subject matter described herein;

FIG. 2 schematically illustrates a method according to an example of the subject matter described herein;

FIG. 3 schematically illustrates a further method according to an example of the subject matter described herein;

FIG. 4 schematically illustrates a yet further method according to an example of the subject matter described herein;

FIG. 5 schematically illustrates a yet further method according to an example of the subject matter described herein; FIG. 6 schematically illustrates formats for Effective Information Packets according to an example of the subject matter described herein;

FIG. 7 schematically illustrates a yet further method according to an example of subject matter described herein;

FIG. 8 schematically illustrates transmission of content according to an example of the subject matter described herein;

FIG. 9 schematically illustrates an apparatus in accordance with an example of the subject matter described herein; and

Fig. 10 schematically illustrates a computer program in accordance with an example of the subject matter described herein.

The figures are not necessarily to scale. Certain features and views of the figures can be shown schematically or exaggerated in scale in the interest of clarity and conciseness. For example, the dimensions of some elements in the figures can be exaggerated relative to other elements to aid explication. Similar reference numerals are used in the figures to designate similar features. For clarity, all reference numerals are not necessarily displayed in all figures.

ABBREVIATIONS/DEFINITIONS

3GPP 3rd Generation Partnership Project

5G/6G 5th/6th Generation

ARQ Automatic Repeat Request

CRC Cyclic Redundancy Check

CSI Channel State Information

EIP Effective Information Packet

ERL Effective Radio Link gNB 5G / NR base station

HARQ Hybrid Automatic Repeat Request

JSCC Joint Source and Channel Coding

LLR Log-Likelihood Ratio

MAC Medium Access Control

NG-RAN New/Next Generation Radio Access Network

NW Network

PDCP Packet Data Convergence Protocol

PHY Physical layer

RAN Radio Access Network

RLC Radio Link Control

RRC Radio Resource Control

UE User Equipment DETAILED DESCRIPTION

FIG. 1 schematically illustrates an example of a network 100 suitable for use with examples of the present disclosure. The network (also referred to as NW) comprises a plurality of network nodes including: terminal nodes 110 (also referred to as User Equipment, UE), access nodes 120 (also referred to as Radio Access Network, RAN, node, or Base Station, BS), and one or more core network nodes 130. The terminal nodes 110 and access nodes 120 communicate with each other. The one or more core network nodes 130 may, in some but not necessarily all examples, communicate with each other. The one or more access nodes 120 may, in some but not necessarily all examples, communicate with each other.

The network 100 is, in this example, a radio telecommunications network, i.e. a RAN, in which at least some of the terminal nodes 1 10 and access nodes 120 communicate with each other using transmission/reception of radio waves.

The network/RAN 100 may be a cellular network comprising a plurality of cells 122 each served by an access node 120. The access nodes 120 comprise cellular radio transceivers. The terminal nodes 110 comprise cellular radio transceivers.

In the particular example illustrated and discussed below, the network 100 is a New Radio, NR, network of the Third Generation Partnership Project, 3GPP, and its fifth generation, 5G, technology. In other examples, the network 100 may be a network beyond 5G, for example a next generation (i.e. sixth generation, 6G) Radio Network that is currently under development (i.e. an evolution of the NR network and its 5G technology).

The interfaces between the terminal nodes 110 and the access nodes 120 are radio interfaces 124 (e.g., Uu interfaces). The interfaces between the access nodes 120 and one or more core nodes 130 are backhaul interfaces 128 (e.g., S1 and/or Next Generation, NG, interfaces).

Depending on the exact deployment scenario, the access nodes 120 may be RAN nodes such as NG-RAN nodes. NG-RAN nodes may be gNodeBs, gNBs, that provide NG user plane and control plane protocol terminations towards the UE. The gNBs connected by means of NG interfaces to a 5G Core (5GC), more specifically to an Access and Mobility Management Function, AMF, by means of an NG Control Plane, NG-C, interface and to a User Plane Function, UPF, by means of an NG User Plane, NG-U, interface. The access nodes 120 may be interconnected with each other by means of Xn interfaces 126.

The cellular network 100 may be configured to operate in licensed frequency bands, or unlicensed frequency bands (not least such as: unlicensed bands that rely upon a transmitting device to sense the radio resources/medium before commencing transmission, such as via a Listen Before Talk, LBT, procedure; and a 60GHz unlicensed band where beamforming may be required in order to achieve required coverage). The access nodes 120 may be deployed in an NG standalone operation/scenario. The access nodes 120 may be deployed in a NG non-standalone operation/scenario. The access nodes 120 may be deployed in a Carrier Aggregation, CA, operation/scenario. The access nodes 120 may be deployed in a Dual Connectivity, DC, operation/scenario, i.e., Multi Radio Access Technology - Dual Connectivity, MR-DC, or NR-DC. The access nodes 120 may be deployed in a Multi Connectivity, MC, operation/scenario.

In such non-standalone/dual connectivity deployments, the access nodes 120 may be interconnected to each other by means of X2 or Xn interfaces, and connected to an Evolved Packet Core, EPC, by means of an S1 interface or to the 5GC by means of a NG interface.

The access nodes 120 are network elements in the network responsible for radio transmission and reception in one or more cells 122 to or from the terminal nodes 110. The access nodes 120 are the network termination of a radio link. Each access node may host one or more Transmission Reception Points, TRPs.

An access node 120 may be implemented as a single network equipment, or have a split architecture that is disaggregated/distributed over two or more RAN nodes, such as a Central Unit, CU, a Distributed Unit, DU, a Remote Radio Head-end, RRH, using different functional-split architectures and different interfaces.

The terminal nodes 110 are network elements in the network that terminate the user side of the radio link. They are devices allowing access to network services. Terminal node 110 functionalities may be performed also by Mobile Termination, MT, part of an Integrated Access and Backhaul, IAB, node. The terminal nodes 110 may be referred to as User Equipment, UE, mobile terminals or mobile stations.

The term 'User Equipment’ may be used to designate mobile equipment comprising means, such as a smart card, for authentication/encryption etc. such as a Subscriber Identity Module, SIM. A SIM/SIM card can be a memory chip, a module, or a Universal Subscriber Identity Module (USIM). In some examples, the term 'User Equipment’ can be used to designate a location/position tag, a hyper/smart, a hyper/smart sensor, or a mobile equipment comprising circuitry embedded as part of the user equipment for authentication/encryption such as a software SIM.

In the following description, a terminal node may be referred to simply as UE 110. In the following description, an access node, a Radio Access Network, RAN, node, a gNB or a TRP may be referred to simply as a network node 120.

The current communication systems have different layers of error detection/correction and retransmission to seek to guarantee a successful transmission of a packet. However, in some scenarios, it may be likely that a requested packet may not be transmitted correctly (despite all available error detection and correction methods) within the given time window. In such situations, conventionally/typically the packet is dismissed and considered as a failure. However, in examples of the disclosure, erroneous packets are considered as useful data for action decisions in some applications, such as remote robotic control.

Typically, under current cellular technologies (including 5G NR), the transmission of a packet of data will go through the following steps. Firstly, a CRC bit sequence is appended to the packet. Channel coding, such as for error detection and correction (e.g. in a codeword), is then applied to the packet to protect it from the transmission channel. The channel coding may comprise Forward Error Correction, FEC, coding. The packet is then modulated onto a constellation and waveform before being transmitted. At the receiver, after channel decoding, the appended CRC bits are checked to see if a decoding error occurred. If an error is detected, a retransmission is requested. If an error is still detected after an allowed number of retransmissions has been reached (e.g. within a latency budget), then the packet is discarded.

Semantic/effective communication is communication where a recipient is interested in semantic information/effect conveyed by a source message rather than requiring an accurate reception of each single symbol or bit. Conventional general semantic/effective communication solutions rely on Joint Source and Channel Coding, JSCC, wherein source encoding (decoding) and channel encoding (decoding) are done jointly so as to minimize the volume of data transfer and to maximize effectiveness of the data transfer. The role of source coding is typically to reduce redundancy in a packet, e.g., by means of compression. The role of channel coding is typically to protect the packet against errors and erasures, typically by adding redundancy. Source coding, typically happens at a source node (e.g., via an application which generates the data), while channel coding usually done at a physical layer of the communication protocol. JSCC is practically infeasible within the way current cellular technologies, e.g. not least 5G NR, are designed.

The application may refer to client side or server side alike.

The inventors of the present invention have appreciated that the semantics/effects of a packet may be able to be captured by a well-designed source coder, if the network is seen as merely a pipe for bits of information. In this regard, even erroneous packets (i.e., which have been decoded incorrectly/inaccurately such as wherein a channel code fails to recover all bit errors) which are typically discarded by the MAC/RLC layer of a cellular network receiver, can be utilized by an application equipped with a well-designed source coder so as to be able to deliver near JSCC level of semantics/effects of the message. Such an application may be a computer program residing on a device, which can be User Equipment, UE, or in the cloud (not least such as an edge or core device).

Examples of the present disclosure may be particularly useful for time-critical applications (where each packet has a time window/latency budget within which the data must be received) and semantic/effective applications. One such example is a heartbeat type control message that is periodically expected from a source (e.g., a remote controller of a robot). In such case, conventionally, each packet has a latency budget where, if the latency budget expires without successful delivery of the packet, the packet is discarded, and the communication system moves on to the next packet in the queue. On the application side, the missing packet may be substituted either by the previously delivered packet (zero hold assumption) or extrapolated using estimation methods. The inventors of the present invention have appreciated that, instead of discarding erroneous packets (as is conventionally done) if the erroneous packets were passed on to the application, the erroneous packets can be beneficial to the application.

Passing the erroneous packet on to the application requires the erroneous packet to bypass radio access layers and core network scrutiny and to be delivered to the application, despite errors in some of the bits. Current conventional technologies do not allow such functionality. Examples of the present disclosure proposes methods to enable a new type of radio link configuration that allows bypassing certain layers of the network layer stack (i.e. bypassing the functions performed by various layers which may include: segmentation, concatenation, compression, header attachment, etc.) to enable the delivery of an erroneous packet, as well as potentially augmenting the erroneous packet - enriching the erroneous packet with additional information to help the application extract semantics from the packet.

Conventional discarding of an erroneous packet (e.g. an erroneously decoded packet) may not optimal, not least for certain applications such as those requiring low latency. For certain applications, even when errors are detected by a receiver, erroneous packets can still be useful to the application. Certain applications, may be able to identify most likely semantics that was intended to be conveyed by a source of the packets.

As will be discussed in further detail below, in certain examples of the present disclosure, the behaviour of an error detection mechanism is modified such that, even if an error is detected in a decoded packet of data, the erroneously decoded packet of data is still nevertheless passed on to a recipient (e.g. an application) rather than simply being disregarded. Moreover, when an error is detected, the erroneously decoded packet may be supplemented/augmented with additional information, such as: channel information, Log- Likelihood Ratio, LLR, of received bits. Such additional information may be useful for the application, e.g. to derive an intended meaning/semantics from the erroneously decoded packet, because the application may use the additional information, instead of or in addition to, the erroneous packet. By way of a non-limiting example, if one were to have a cloudbased controller that remotely controlled a robot by sending action commands via a wireless channel, the remotely controlled robot may choose to use LLR information from an erroneously decoded packet and determine a top K most likely actions. The remotely controlled robot can then determine which of those K action to take based on its current context, e.g. observations of its surroundings. For instance, if there were an obstacle near the robot and one of those K actions include an action that collides with the obstacle, then it would be unlikely that such an action was the intended action. FIG. 2 schematically illustrates a method 200 according to an example of the subject matter described herein.

The component blocks of FIG. 2 are functional, and the functions described can be performed by a single physical entity, such as an apparatus that receives a packet to be decoded (e.g. embodied either as a UE or network node), as described with reference to FIG. 9. The functions described can also be implemented by a computer program, such as is described with reference to FIG. 10. The blocks illustrated in FIG. 2 can therefore represent actions in a method, functionality performed by an apparatus, and/or sections of instructions/code in a computer program.

In block 201 , an apparatus receives configuration information 202 for configuring the apparatus to operate in an operational mode 203.

As will be described in further detail with regards to FIG. 3, the operational mode 203 is a mode of operation of the apparatus wherein: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated that comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient.

The determination that the at least first packet has been erroneously decoded may comprise detecting the decoding error after: a single transmission ('one-shot’ transmission) of the packet; one or more retransmissions of the packet (i.e. an allowed number of retransmissions); and/or plural attempts for error correction and retransmission within a given time window/latency budget.

Please consider adding both options of decoding error after one-shot transmission and decoding error after retransmission and decoding as Hamid mentioned above.

In block 204, the apparatus operates in the operational mode 203.

In this regard, the apparatus may apply the received configuration information 202 and operate in the configured operational mode 203. In this operational mode, responsive to detection of a decoding error of a received first packet, instead of simply disregarding the erroneously decoded first packet, the apparatus generates a second packet (that comprises information from the erroneously decoded first packet), and the second packet is passed on to a recipient.

In some examples, the configuration information comprises information for configuring the apparatus to bypass one or more layers of a radio access network stack. In some examples, passing the second packet on to the recipient may comprise at least one of the following: passing the at least second packet to an application layer; passing the second packet from a Medium Access Control layer of the apparatus to an application layer of the apparatus; bypassing one or more radio access network protocol stack layers; and transferring the at least second packet to an application residing on the apparatus.

In some examples, the apparatus is a UE and the configuration information is received from a gNB or vice versa. In other examples, the apparatus is a gNB and the configuration information is received from another network node, not least such as a core node of a RAN, or vice versa.

FIG. 3 schematically illustrates a method 300 showing an apparatus 10 (e.g. a UE 110 or gNB 120 of a RAN) operating in the operational mode 203 (i.e. as per block 202 of FIG. 2), i.e. following receipt of configuration information 202 [not shown] (i.e. as per of block 201 of FIG. 2).

In the below described example of FIG. 3, a downlink scenario is discussed, namely wherein the apparatus 10 is a UE 110 that, having performed the steps 201 and 202 of the method 200 of FIG. 2, operates in the operational mode 203 with regards to a packet received from a gNB. However, it is to be appreciated that in other examples, e.g. an uplink scenario, the apparatus could be a gNB that, having performed the steps 201 and 202 of the method 200 of FIG. 2, operates in the operational mode 203 with regards to a packet received from a UE.

In block 301 , the apparatus 10, i.e. UE 110, receives a first packet 302 from a gNB 120. The first packet may itself originate from a source device, e.g. a remote server or another UE, and be conveyed to the gNB for transmission to the UE via a User Plane Function of the RAN (not shown).

In examples where the apparatus 10 is a gNB, the gNB may receive the first packet from, e.g. a User Plane Function of a RAN (wherein the first packet is itself originates from a source device, e.g. a remote server or another UE).

In block 303, the apparatus decodes the first packet.

In block 304, the apparatus determines whether there has been an error in the decoding of the first packet.

The determination of whether there has been an error in the decoding of the first packet may comprise one or more of the following: detecting an error in the decoded first packet; detecting an error in a channel decoding process performed on the at least first packet; detecting a failure of a cyclic redundancy check, CRC; and detecting that a latency for the at least first packet exceeds a threshold.

In block 305, responsive to determining that the first packet has been erroneously decoded, the apparatus determines information 306 from the erroneously decoded first packet.

Such information 306 may comprise one or more of the following: decoded symbols of the first packet; hard decoded bits of the first packet. These may correspond to the erroneously decoded hard coded bits (which may be derived from a process that takes LLRs and makes hard - usually binary - decisions on the same); soft decoded bits (e.g. LLRs, or other soft metric that indicates confidence levels of hard decoded bits); codewords derived from the erroneously decoded first packet; and a list of a number, K, of the most likely codewords based on soft decoded bits (e.g. LLR values) associated with the erroneously decoded first packet.

Hard bits/symbols, may refer to a situation where a hard decision is made for a value of a bit/symbol based on a possible constellation of values. Soft bits/symbols may refer to a situation where a confidence level is associated to a value but no hard decision is made as to the value.

As will be discussed in further detail below, e.g. with reference to FIG. 6, in some examples, the information may additionally comprise: an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

In block 307, responsive to determining that the at least first packet has been erroneously decoded, the apparatus generates a second packet 308 that comprises the information 306 determined in step 305.

The second packet may further comprise at least one of the following: information indicative of a state of a channel via which the at least first packet was conveyed (e.g. Channel State Information, CSI); information indicative of a decoding process via which the at least first packet was decoded.

In block 309, the apparatus transfers the second packet to a recipient (310).

In some examples, the recipient could be: an application layer of a RAN/3GPP layer stack; an application/software program residing on the apparatus. a core node of a RAN; a User Plane Function; or a node of another RAN.

In some examples, the configuration information 202 (which is previously received in block 201 of FIG. 2) may comprise an identifier of an application residing on the apparatus. In some examples, such an identifier may serve to indicate that the application is to be the recipient to whom the second packet is to be transferred to, i.e. to identify the application as the recipient such that the second packet is transferred to the application in block 309.

In some examples, the generated second packet may have a particular packet format. The packet format may be preconfigured. The packet format may be pre-determined between an application of the apparatus (e.g. the application that is to receive the second packet) and a second apparatus/device that is the source of the first packet.

The configuration information received in block 201 of FIG. 1 may comprise an indication of a packet format that the generated second packet is to have.

The packet format may indicate whether the generated second packet is to comprise at least one of the following: an indication for identifying the second packet as a packet that is generated, based on the determination that the first packet has been erroneously decoded; an indication for identifying the second packet as a particular type of packet that comprises information from the erroneously decoded first packet; an indication that the first packet was erroneously decoded; one or more decoded symbols of the first packet; one or more hard coded bits of the first packet; one or more soft coded bits indicative of one or more confidence levels of one or more hard decoded bits of the first packet; one or more Log Likelihood Ratio, LLR, values; one or more codewords derived from the erroneously decoded at least first packet; one or more of the most likely codewords based at least in part on LLR values; an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

The formatting of the second packet are discussed further below with regard to FIG. 6.

The component blocks of FIG. 3 are functional, and the functions described can be performed by a single physical entity, such as an apparatus (e.g. embodied either as a UE or network node), as described with reference to FIG. 9. The functions described can also be implemented by a computer program, such as is described with reference to FIG. 10. The blocks illustrated in FIG. 3 can therefore represent actions in a method, functionality performed by an apparatus, and/or sections of instructions/code in a computer program. FIG. 4 schematically illustrates a method 400 according to an example of the subject matter described herein, wherein the method is performed by an apparatus, namely a gNB 120.

In block 401, the gNB receives, from a UE, a request 401 to operate in an operational mode, namely the operational mode 203 as described above.

The request may comprise a request to establish a radio link between the UE (i.e. which is to be a recipient of the first packet) and a second apparatus that is a source of the at least first packet, wherein the radio link is configured such that, for packets transmitted via the radio link, the UE operates in the operational mode 203.

In this regard, requesting the establishment of the radio link comprises requesting at least one of the following: one or more layers of a radio access network stack be bypassed during reception and/or transmission of packets conveyed via the radio link; one or more layers above a Media Access Control, MAC, or Physical, PHY, layer be bypassed during reception and/or transmission of packets conveyed via the radio link; a particular modulation scheme be used for the transmission of packets conveyed via the radio link; a particular modulation constellation be used for the transmission of packets conveyed via the radio link; a particular coding scheme be used for the transmission of packets conveyed via the radio link; or a particular code rate and/or type be used for the transmission of packets conveyed via the radio link.

The request may comprise at least one of the following: an identifier of an application residing on the UE (e.g. for indicating that the recipient in block 309 is to be the application); and a request for a particular packet format for the second packet (e.g. for indicating which format is to be adopted for the generation of the second packet in block 307, and hence which information 306 is to be determined in block 305 and included in the generated second packet.

The various parameters of the request, and parameter values of the same may be ascertained and agreed upon in a handshake procedure during the establishment of the radio link. The various parameters and parameter values may typically be decided by the gNB. However, it may be beneficial for the application to have impact on the parameters/ parameter values so as to enable joint source channel optimization. Certain choices/options that may be available for the radio link to be established include: a transparent mode for the link, wherein RAN layers are bypassed with no header/segmentation, etc. down to lower MAC/PHY where channel coding is used for FEC and potentially HARQ; choice of modulation constellation: this gives the application more flexibility in an effective joint source channel coding process; e.g. the application may choose to use a fixed modulation constellation that bypasses the channel-dependent Adaptive Modulation and Coding, AMC; choice of channel code rate / type, and decoding iterations: such parameters can be chosen e.g. based on the type of source code the application is using.

The above choices can be made in order to seek to provide a more controlled data link layer (i.e. a controllably reliable bit pipe).

In block 403, responsive to receipt of the request, the gNB determines configuration information for configuring the UE to operate in the operational mode. The configuration information (i.e. configuration information 202 as described above with regards to FIG. 2) may be determined/generated is based at least in part on the request, e.g. so as to configure the UE to generate the second packet in accordance with the packet format and information content requested in the request. In instances where a particular packet format and information content for the second packet is not requested by the UE, a default packet format and information content for the second packet may be used, e.g. as defined in a standard.

In block 404, the gNB sends the configuration information to the UE (this step effectively corresponds to block 204 of FIG. 2).

In the above described example, the apparatus that performs the method 400 has been described as being a gNB 120, i.e. a gNB that determines and sends configuration information to a UE to configure the UE to operate in the operational mode. However, it is to be appreciated that in other examples, the apparatus that performs the method 400 could be a core node that determines and sends configuration information to a gNB to configure the gNB to operate in the operational mode.

The component blocks of FIG. 4 are functional, and the functions described can be performed by a single physical entity, such as an apparatus (e.g. embodied either as a UE or network node), as described with reference to FIG. 9. The functions described can also be implemented by a computer program, such as is described with reference to FIG. 10. The blocks illustrated in FIG. 2 can therefore represent actions in a method, functionality performed by an apparatus, and/or sections of instructions/code in a computer program.

While in typical/conventional radio access technologies, an erroneous data packet is discarded at the receiver part of a radio access network (e.g. receiver part of a UE or receiver part of a gNB), the inventors of the present invention have appreciated that even erroneous data can be useful by an application that is interested in capturing semantics of a received message. For example, by passing a top K most likely codewords after erroneous channel decoding to the application, the application can check which codeword gives a highest value to the application according to an externally prescribed function. Such functions would be application specific and constitutes a description of semantic value.

In this regard, a new type of end-to-end radio link is proposed wherein received packets can be enriched, along the way from a transmitter to a receiver, with additional information. This can be especially useful when the wireless link is in a troubled state that would conventionally result in erroneous packet delivery and outage in typical radio link setups.

In examples of the present disclosure, a receiver method of decoding and packet delivery is proposed where, instead of discarding an erroneous packet, it is augmented with additional information (e.g.: not least about a state of a channel, a decoding process, a confidence level of error) which may be helpful to capturing semantics of a message, the erroneous packet, combined with such additional data is passed on to the application.

In examples of the present disclosure, a method is proposed of capturing the state of a channel and radio access network function that will be usable by the semantic/effective communication application, followed by creating an Effective Information Packet, EIP, that conveys such additional information.

This may be particularly beneficial for semantic/effective communication applications where source and channel coding functions are designed to operate separately (such as is the case for all cellular technologies, including LTE and 5G NR). Thus, joint source and channel coding are not applicable to capture the semantics of a message.

For instance, an effective control application may include a heartbeat type flow of control messages periodically received from a source (e.g., remote cloud controller operating a robot on a factory floor).

The proposed method effectively treats a radio link as a 'best effort pipe for information bits’ (i.e., a link that offers a best effort to deliver a packet with best effort bit error rate) for such applications. By sharing the additional information in the EIP with the application, it allows the application to seek to most optimally capture the semantics of the intended message, thus maintaining a smooth operation for the application while most efficiently using the communication link.

For semantic communications and effective communications applications where Joint Source and Channel Coding, JSCC, is not available, erroneous packets out of channel decoding can be useful to effective communications applications. Error detection is usually done using CRC codes embedded in segments of a packet as well as in a larger transport block. Generally, within a latency budget of the packet, there might be one or few transmission attempts possible (e.g., controlled by a HARQ or ARQ process). A 'channel decoding error’ in the following refers to the final decoding when all the retransmission attempts are used, and the process must decide to declare the packet as erroneous and empty the process buffer. For such applications a new paradigm of decoding and packet delivery is proposed as follows:

Step 1 : a semantic/effective application uses an identifier to inform a RAN and/or core network functions and requests an 'Effective Radio Link’, ERL. Consequently, an ERL is established for the semantic/effective application (e.g., in end-to-end fashion between semantic/effective application and a service, or a multitude of nodes connected to the same semantic/effective application/service), wherein packets that are received by a receiver (e.g. of a UE) and which are erroneously decoded by a decoding layer of the receiver are passed on to the semantic/effective application using a pre-configured packet format. In this regard, the ERL can effectively be considered to be a virtual link established between two ends (e.g. a client/user semantic application and a server/semantic service provider) which has different attributes and configurations compared to typical communication links.

Step 2: upon detection of a channel decoding error over the ERL, instead of discarding the packet, an 'Effective Information Packet’ EIP containing all or some of the following additional information is created by the decoding layer of the receiver: erroneous decoding acknowledgement erroneous hard coded bits of the packet (i.e., CRC check failed)

Log-Likelihood Ratios, LLRs, of the decoded bits prior to the hard decoding process (the LLRs may be quantized into/limited to a pre-configured number of quantization levels that fits an EIP allowance, i.e. the number of bits/an amount of data/size permitted for the EIP).

K most likely codewords according to the LLRs for segmented packets (e.g., Transport Block, TB, segmented into multiple Code Blocks, CBs), a map or index of erroneous segments (e.g., some CBs may pass the CRC check, while one or a few may fail it, thus, TB CRC also fails)

Step 3: the semantic/effective application receives the EIP. Using the preconfigured EIP format, the semantic/effective application identifies the erroneous packet and utilizes it, e.g., together with semantic/effective application source decoding, to identify a most likely semantics (also referred to as, intentions, action) that was intended by the source of the original packets.

Some implementations may involve multiple-hops, and hence a multi-hop channel. In such cases, the EIP may need to go through one or more wireless links before being delivered to the semantic/effective application. Therefore, the ERL needs to be able to treat EIPs differently from normal packets. That is, in case of receiving an EIP, the network node/RAN identifies a header part of an El P, and treats each data segment of the El P (such as shown in highlighted blocks of Fig. 6) as data packets.

FIG. 5 schematically illustrates a method in accordance with an example of the present disclosure. The operations shown in FIG. 5 can be broadly grouped into two groups/steps: Step 1 - concerning application identification and configuration, and Step 2 - concerning modifying receiver operation of an effective radio link.

In FIG. 5, a time flow of operation among different functions in the core and radio access network functions in step 1 are depicted, while two examples for downlink and uplink cases are also shown for step 2.

In Step 1 , the following operations may be performed:

The semantic/effective application is identified, e.g., using an application identifier, by the radio access network or the core network, to enable an effective radio link for the application. The application can be identified by any means. For example the UE may ask NW to identify the application, or the NW itself can identify the application. In some examples, the application uses an identifier which informs the RAN or core functions that even erroneously decoded packets are to be passed on to the application using a preconfigured EIP format. The application identifier can be e.g., a traffic type or QoS identifier.

In some examples, a user application (i.e. an application/software program at a UE) - which is referred to herein as an "effective application” or a "semantic application” - is identified by a RAN and/or a core node (e.g. via an Application function) to enable an effective radio link for the user application. Such identification may be effected via the use of an application identifier. The application identifier can be e.g., a traffic type or QoS identifier. The RAN and/or core node uses the application identifier to enable an effective link for the user application.

One example implementation of such a method is to effect a bypassing of a packet in an effective radio link through layers of the radio access network stack to and from a lower layer, e.g., the lower MAC HARQ layer or the PHY layer. This includes configuring the layers and functions of the radio access to be bypassed or modified for the effective radio link, e.g., configuring the bypass of PDCP, RLC and MAC multiplexing to pass the packet directly to and from a channel HARQ process.

In wireless systems, it is common to perform ciphering on an application or an IP packet before passing it on to RAN functions. In case of stream encryption methods, such as NR/5G Encryption Algorithm, NEA, this would not create issues for EIP creation. The bit stream of the decryption must be binary added bit by bit to each and every single version of an erroneous packet, including an LLR version (toggling the LLR if 1 and keeping it if 0). In case of block encryption however, erroneous bits in the EIP would likely propagate in the decryption process. As a result, in such cases, it is best if an encryption function of the RAN is bypassed (the configuring of such a bypass may be effected in Step 1 ) for the effective radio link. Instead, the user application itself can encrypt the data before transmission using a stream encryption such that the erroneous EIP can be accordingly deciphered at a receiver. In Step 2, the following operations may be performed.

When a packet is detected as erroneous (e.g., a transport block, after an allowed number of HARQ retransmissions, fails a CRC check), an Effective Information Packet, EIP, is created by the receiver (e.g., at the lower MAC layer) and passed on to the application layer, e.g. passed on to the application so that the application itself may seek to perform semantic extraction from the erroneous packet. In this regard, the application may receive the EIP from its corresponding radio client. Using the EIP configuration information, a header of the EIP is read and removed from the EIP. Then, the erroneous packet is utilized, e.g., together with source decoding, to identify a most likely message that was intended by the source of the packet.

The EIP may contain an identifier using which a regular packet transmission vs EIP transmission can be distinguished over an effective radio link.

The EIP may contain all or some of the following options (as depicted and discussed further in FIG. 6):

Option a) Erroneous decoding acknowledgement: which acknowledges that the packet was incorrectly decoded at the radio function.

Option b) Erroneous hard coded bits of the packet: this contains the decoded binary bits of the packet, e.g., after removing the CRC bits when the CRC check is failed for the packet.

Option c) Log-Likelihood Ratios, LLRs: this content reports the LLRs (or a similar soft metric of the symbols/bits of the decoded packet) of the decoded bits prior to the hard decoding process. The LLRs of the CRC bits are removed from the packet. The LLRs may be quantized into a pre-configured number of quantization levels based on a pre-configured EIP configuration. The quantization level and method used may be indicated/noted in a quantization header.

Option d) K most likely codewords: The decoding process, in case of decoding failure, may output a list of K most likely codewords which are derived e.g. from the raw LLRs. For instance, a Polar code decoder may create a list of the K most likely codewords. A header may be attached to define/contain the size of the list, K.

Option e) segmented EIP: For segmented packets, e.g., a Transport Block, TB, which is segmented into multiple Code Blocks, CBs, it is likely that one or few of the CBs fail in decoding while the others are successfully decoded. In such a case, the EIP may contain a correctly decoded version of the latter, while also providing information about the erroneous CBs (e.g. one or more of the options b, c, and d). A map of the erroneous bits or CBs may be created in such case. Or, alternatively, an index of erroneous segments may be listed.

Step 1 is illustrated in FIG. 5 with regards to operations 1 to 4.

In operations 1 a and/or 1 b EIP configuration information is determined/established. Such configuration information may include, not least, information for defining the format and content (such as is discussed with respect to FIG. 6) that is to be employed for an EIP in the event that a packet (sent to or sent from a user application, e.g. a client-side effective/semantic application residing on a user device) is erroneously decoded (e.g. by a radio client of a user device (e.g. UE 110) or a RAN node (e.g. gNB 110)), and responsive to the same, an EIP is generated in accordance with the EIP configuration information.

In this regard, a handshaking procedure may be performed, via operations 1 a and/or 1 b, to establish/agree on the configuration, e.g. format and content, of any EIPs that are to be generated in the event there is a decoding error of received/transmitted packets.

In operation 2, an application function sends, to a network exposure function, an ERL service request. The ERL service request may comprise an application type (e.g. type of user application), application identifier (e.g. identifier for the user application) as well as the EIP configuration established in operations 1 a and 1 b.

In operation 3, responsive to receipt of the ERL service request, the network exposure function sends, to a RAN and a radio client of a user device, and ERL establishment request. The ERL establishment request may comprise the EIP configuration and also configuration information for bypassing layers of the radio network stack. This operation effectively corresponds to step 201 of FIG. 2.

In operation 4, responsive to receipt of the ERL establishment request, the RAN establishes the ERL. In this regard, an ERL may be established between a RAN node and a radio client (e.g. transceiver/decoder) of the user device. The establishment of the ERL effectively comprises the RAN node and radio client being configured in an operational mode such that, if a packet received by the radio client or RAN node is erroneously decoded by the radio client or RAN node, an EIP generated transferred to a recipient. The recipient may be, for example in downlink, the user application, or in uplink another device (e.g. a second user application or a server-side effective/semantic application or service provider [not shown]).

Step 2 is illustrated in FIG. 5 with regards to operations 5 and 6 for a downlink example, and operations 7 and 8 for an uplink example. These operations effectively corresponds to step 204 of FIG. 2.

In the downlink example, the Radio client receives a packet from the RAN [not shown] and performs a channel decoding procedure on the received packet [not shown]. In operation 5, a channel decoding error is detected at the end of a latency budget for the packet. This operation effectively corresponds to step 304 of FIG. 3.

In operation 6 (which effectively corresponds to step 309 of FIG. 3.), responsive to detecting the channel decoding error in operation 5, an EIP is generated and delivered to the user application. The user application may then use the EIP to seek to extract semantics therefrom, i.e. to seek to identify the intended semantics from the initially received (and erroneously decoded) packet. In this regard, the application may use the EIP, together with prior knowledge of source decoding for the packet, to identify a most likely message that was intended by the source of the packet.

In the uplink example, the RAN receives a packet from the radio client [not shown] and performs a channel decoding procedure on the received packet [not shown]. In operation 7, a channel decoding error is detected at the end of a latency budget for the packet. This operation effectively corresponds to step 304 of FIG. 3.

In operation 8 (which effectively corresponds to step 309 of FIG. 3.), responsive to detecting the channel decoding error in operation 7, an EIP is generated and delivered to a user plane function (e.g. for subsequent delivery to a recipient, e.g. a second user application or serverside effective/semantic application or service provider), so that the recipient may use the EIP to seek to extract semantics therefrom, i.e. to seek to identify the intended semantics from the initially received packet.

Examples of the present disclosure may thereby enable a transfer of semantics of an erroneously decoded packet to the recipient, thereby providing semantic/effective communication.

FIG. 6 schematically illustrates possible formats for an Effective Information Packet, EIP 308. The EIP 308 comprises an outer header and EIP contents.

The EIP outer header comprises: an El P/regular packet identifier, e.g. to identifier that the packet is an El P as opposed to a regular packet; an erroneous decoding acknowledgement; an EIP type, which is indicative of the content of the EIP, namely whether the EIP content comprises: hard coded bits, LLRs and/or K most likely codewords; and a segmentation identifier for indicating a segmented packet or a non-segmented packet.

For a segmented packet, the EIP contents may comprise: a segmentation header; a correctly decoded part of the packet; and an erroneously decoded part of the packet.

For a non-segmented packet, the EIP contents may comprise: the erroneous packet.

The data segments of the EIP as shown in FIG. 6 as highlighted blocks, i.e. with thicker outlines.

Depending on the EIP type (indicated in the EIP type of the outer header), the erroneously decoded part of the packet or the erroneous packet of the EIP content may comprise: hard coded bits (i.e. for or EIP type = hard coded bits); a quantisation header and quantized LLRs (i.e. for or EIP type = LLRs); and/or a header defining K, and codewords 1 to K (i.e. for or EIP type = K most likely codewords).

The format of the EIP, including which of the various above-mentioned options that are to be are employed in the EIP, may be established and agreed upon in the handshaking procedure 1 a and 1 b of FIG. 5

FIG. 7 schematically illustrates an example of a time flow of operation for a single-hop EIP (namely operations 2 and 3 of FIG. 7) and a multi-hop EIP (namely operations 4 to 9 of FIG. 7).

In operation 1 , an end-to-end ERL is established and EIP configuration information is determined between user 1 application and user 2 application.

A user 1 radio client receives a packet from RAN 1 [not shown] and performs a channel decoding procedure on the received packet [not shown]. In operation 2, a channel decoding error is detected, at the user 1 radio client, by an end of a latency budget for the packet. This operation effectively corresponds to step 304 of FIG. 3.

In operation 3, responsive to detecting the channel decoding error in operation 2, an EIP is generated and delivered to the user 1 application. This operation effectively corresponds to step 309 of FIG. 3.

A RAN 1 receives a packet from user 1 client [not shown] and performs a channel decoding procedure on the received packet [not shown]. In operation 4, a channel decoding error is detected, at RAN 1 , by an end of a latency budget for the packet. This operation effectively corresponds to step 304 of FIG. 3.

In operation 5, responsive to detecting the channel decoding error in operation 4, an EIP is generated and delivered to a second radio access network, RAN 2, e.g. via a User Plane Function, UPF. This operation effectively corresponds to step 309 of FIG. 3.

In operation 6, the RAN 2 detects that the received EIP is an EIP as opposed to a regular packet. Such detection may be effected by using the 'ElP/regular packet identifier’ of an EIP outer header of an EIP as shown in FIG. 6).

In operation 7, the RAN 2 sends the EIP to the user 2 radio client.

The user 2 radio client receives the EIP from RAN 2 and performs a channel decoding procedure on the received EIP. In operation 8, a channel decoding error is detected, at user 2 radio client, by an end of a latency budget for the packet (i.e. the EIP). This operation effectively corresponds to step 304 of FIG. 3. In operation 9, responsive to detecting the channel decoding error in operation 8, a second EIP is generated (i.e. an EIP of the first EIP of operation 5) and the second EIP, which may be referred to as a "two-hop” EIP, is delivered to a user 2 application. This operation effectively corresponds to step 309 of FIG. 3.

In instances where an ERL includes more than one hop of wireless channel (by way of a non-limiting example such as a wireless controller communicating through cellular network with a wireless robot), an EIP may need to go through one or more wireless links before being delivered to a recipient/application.

Therefore, a wireless link that is part of an ERL would need to be able to treat EIPs differently from normal packets. That is, in case of receiving an EIP, the wireless access may identify header parts of the EIP, and treat each data segment of the EIP (namely the highlighted blocks of FIG. 6) as data packets, as shown in FIG. 8.

FIG. 8 schematically illustrates an example transmission of content during a second hop of a two hop ERL.

The resulting EIP of the second hop may be the same size or a different size compared to the first hop EIP, e.g., in case of K most likely codewords, the second hop may generate J most likely codewords for each of the K codewords of the first hop EIP.

FIG. 9 schematically illustrates a block diagram of an apparatus 10 for performing the methods, processes, procedures and signalling described in the present disclosure and illustrated in FIGs. 2 to 8. In this regard the apparatus can perform the roles of a UE 110 or a gNB 120, in the methods illustrated and described above. The component blocks of FIG. 9 are functional and the functions described can be performed by a single physical entity.

The apparatus comprises a controller 11 , which could be provided within a device such as a UE 110 or a gNB 120

The controller 11 can be embodied by a computing device, not least such as those mentioned above. In some, but not necessarily all examples, the apparatus can be embodied as a chip, chip set, circuitry or module, i.e. for use in any of the foregoing. As used here 'module’ refers to a unit or apparatus that excludes certain parts/components that would be added by an end manufacturer or a user.

Implementation of the controller 11 can be as controller circuitry. The controller 11 can be implemented in hardware alone, have certain aspects in software including firmware alone or can be a combination of hardware and software (including firmware).

The controller 11 can be implemented using instructions that enable hardware functionality, for example, by using executable instructions of a computer program 14 in a general- purpose or special-purpose processor 12 that can be stored on a computer readable storage medium 13, for example memory, or disk etc, to be executed by such a processor 12.

The processor 12 is configured to read from and write to the memory 13. The processor 12 can also comprise an output interface via which data and/or commands are output by the processor 12 and an input interface via which data and/or commands are input to the processor 12. The apparatus can be coupled to or comprise one or more other components 15 (not least for example: a radio transceiver, sensors, input/output user interface elements and/or other modules/devices/components for inputting and outputting data/commands).

The memory 13 stores instructions such as a computer program 14 comprising such instructions (e.g. computer program instructions/code) that controls the operation of the apparatus 10 when loaded into the processor 12. The instructions of the computer program 14, provide the logic and routines that enables the apparatus to perform the methods, processes and procedures described in the present disclosure and illustrated in FIGs. 2 and 3. The processor 12 by reading the memory 13 is able to load and execute the computer program 14.

The instructions may be comprised in a computer program, a non-transitory computer readable medium, a computer program product, a machine readable medium. The term "non-transitory,” as used herein, is a limitation of the medium itself (i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM). In some but not necessarily all examples, the computer program instructions may be distributed over more than one computer program.

Although the memory 13 is illustrated as a single component/circuitry it can be implemented as one or more separate components/circuitry some or all of which can be integrated/removable and/or can provide permanent/semi-permanent/ dynamic/cached storage.

Although the processor 12 is illustrated as a single component/circuitry it can be implemented as one or more separate components/circuitry some or all of which can be integrated/removable. The processor 12 can be a single core or multi-core processor.

The apparatus can include one or more components for effecting the methods, processes and procedures described in the present disclosure and illustrated in FIGs. 2 to 8. It is contemplated that the functions of these components can be combined in one or more components or performed by other components of equivalent functionality. The description of a function should additionally be considered to also disclose any means suitable for performing that function. Where a structural feature has been described, it can be replaced by means for performing one or more of the functions of the structural feature whether that function or those functions are explicitly or implicitly described.

Although examples of the apparatus have been described above in terms of comprising various components, it should be understood that the components can be embodied as or otherwise controlled by a corresponding controller or circuitry such as one or more processing elements or processors of the apparatus. In this regard, each of the components described above can be one or more of any device, means or circuitry embodied in hardware, software or a combination of hardware and software that is configured to perform the corresponding functions of the respective components as described above.

The apparatus can, for example, be: a wireless communications device, a client device, a location/position tag, a hyper tag, a hand held portable electronic device, a mobile cellular telephone, a server device, a base station in a mobile cellular telecommunication system etc. The apparatus can be embodied by a computing device, not least such as those mentioned above. However, in some examples, the apparatus can be embodied as a chip, chip set, circuitry or module, i.e. for use in any of the foregoing.

In some examples, the apparatus may be a memory access device that applies a memory access protocol corresponding to the method and functionality of the present disclosure, e.g. not least the functional operations of FIG. 3, albeit wherein the transmitter of the packet, the receiver of the packet, and the recipient/application, all are pieces of hardware/software of the same memory access device. In this instance, the channel may correspond to a data storage unit which may overtime experience errors. In other words, instead of the link being a wireless link, the link may be a communication link, data transmission link or bus between the source of a packet to be transmitted (e.g. data storage unit such as a memory) and a receiver of the packet.

In examples where the apparatus is provided within a UE 110 or gNB 120, the apparatus comprises: at least one processor 12; and at least one memory 13 storing instructions that, when executed by the at least one processor 12, cause the apparatus at least to: receive, at an apparatus, configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operate the apparatus in the operational mode based at least in part on the configuration information. In examples where the apparatus is provided within a gNB 120, the apparatus comprises: at least one processor 12; and at least one memory 13 storing instructions that, when executed by the at least one processor 12, cause the apparatus at least to: receive, from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determine, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information.

According to some examples of the present disclosure, there is provided a system comprising at least one UE 110 and a gNB 120 as described above.

The above described examples find application as enabling components of: tracking systems, automotive systems; telecommunication systems; electronic systems including consumer electronic products; distributed computing systems; media systems for generating or rendering media content including audio, visual and audio visual content and mixed, mediated, virtual and/or augmented reality; personal systems including personal health systems or personal fitness systems; navigation systems; user interfaces also known as human machine interfaces; networks including cellular, non-cellular, and optical networks; ad-hoc networks; the internet; the internet of things (loT); Vehicle-to-everything (V2X), virtualized networks; and related software and services.

The apparatus can be provided in an electronic device, for example, a mobile terminal, according to an example of the present disclosure. It should be understood, however, that a mobile terminal is merely illustrative of an electronic device that would benefit from examples of implementations of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure to the same. While in certain implementation examples, the apparatus can be provided in a mobile terminal, other types of electronic devices, such as, but not limited to: mobile communication devices, hand portable electronic devices, wearable computing devices, portable digital assistants (PDAs), pagers, mobile computers, desktop computers, televisions, gaming devices, laptop computers, cameras, video recorders, GPS devices and other types of electronic systems, can readily employ examples of the present disclosure. Furthermore, devices can readily employ examples of the present disclosure regardless of their intent to provide mobility.

FIG. 10, illustrates a computer program 14 which may be conveyed via a delivery mechanism 20. The delivery mechanism 20 can be any suitable delivery mechanism, for example, a machine readable medium, a computer-readable medium, a non-transitory computer-readable storage medium, a computer program product, a memory device, a solid-state memory, a record medium such as a Compact Disc Read-Only Memory (CD- ROM) or a Digital Versatile Disc (DVD) or an article of manufacture that comprises or tangibly embodies the computer program 14. The delivery mechanism can be a signal configured to reliably transfer the computer program. An apparatus can receive, propagate or transmit the computer program as a computer data signal.

In certain examples of the present disclosure, there is provided a computer program comprising instructions, which when executed by an apparatus (UE 110), cause the apparatus to perform at least the following or for causing performing at least the following: receiving, at an apparatus, configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and operating the apparatus in the operational mode based at least in part on the configuration information.

In certain examples of the present disclosure, there is provided computer program comprising instructions, which when executed by an apparatus (gNB 120), cause the apparatus to perform at least the following or for causing performing at least the following: receiving, at a first apparatus from a second apparatus, a request to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the second apparatus has been erroneously decoded by the second apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; determining, based at least in part on the request, configuration information for configuring the second apparatus to operate in the operational mode; and sending, to the second apparatus, the configuration information.

References to 'computer program’, 'computer-readable storage medium’, 'computer program product’, 'tangibly embodied computer program’ etc. or a 'controller’, 'computer’, 'processor’ etc. should be understood to encompass not only computers having different architectures such as single /multi- processor architectures and sequential (Von Neumann)/parallel architectures but also specialized circuits such as field-programmable gate arrays (FPGA), application specific circuits (ASIC), signal processing devices and other devices. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

As used in this application, the term 'circuitry’ can refer to one or more or all of the following:

(a) hardware-only circuitry implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions and

(c) hardware circuit(s) and/or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (for example firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Features described in the preceding description can be used in combinations other than the combinations explicitly described.

Although functions have been described with reference to certain features, those functions can be performable by other features whether described or not.

Although features have been described with reference to certain examples, those features can also be present in other examples whether described or not. Accordingly, features described in relation to one example/aspect of the disclosure can include any or all of the features described in relation to another example/aspect of the disclosure, and vice versa, to the extent that they are not mutually inconsistent.

Although various examples of the present disclosure have been described in the preceding paragraphs, it should be appreciated that modifications to the examples given can be made without departing from the scope of the invention as set out in the claims. For instance, whilst examples of the disclosure have been described with respect to a radio link, in some examples other types of links may be used, e.g. other types of wireless links or a wired link. The term 'comprise’ is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising Y indicates that X can comprise only one Y or can comprise more than one Y. If it is intended to use 'comprise’ with an exclusive meaning then it will be made clear in the context by referring to "comprising only one ...” or by using "consisting”.

In this description, the wording 'connect’, 'couple’ and 'communication’ and their derivatives mean operationally connected/coupled/in communication. It should be appreciated that any number or combination of intervening components can exist (including no intervening components), i.e. so as to provide direct or indirect connection/coupling/communication. Any such intervening components can include hardware and/or software components.

As used herein, the term "determine/determining" (and grammatical variants thereof) can include, not least: evaluating, calculating, computing, processing, deriving, measuring, investigating, identifying, looking up (for example, looking up in a table, a database or another data structure), ascertaining and the like. Also, "determining" can include receiving (for example, receiving information), retrieving/accessing (for example, retrieving/accessing data in a memory), obtaining and the like. Also, " determine/determining" can include resolving, selecting, choosing, establishing, inferring and the like.

As used herein, a description of an action should also be considered to disclose enabling, and/or causing, and/or controlling that action. For example, a description of transmitting information should also be considered to disclose enabling, and/or causing, and/or controlling transmitting information. Similarly, for example, a description of an apparatus transmitting information should also be considered to disclose at least one means or controller of the apparatus enabling, and/or causing, and/or controlling the apparatus to transmit the information.”

The term "means” as used in the description and in the claims may refer to one or more individual elements configured to perform the corresponding recited functionality or functionalities, or it may refer to several elements that perform such functionality or functionalities. Furthermore, several functionalities recited in the claims may be performed by the same individual means or the same combination of means. For example performing such functionality or functionalities may be caused in an apparatus by a processor that executes instructions stored in a memory of the apparatus.

References to a parameter, or value of a parameter, should be understood to refer to "data indicative of”, "data defining” or "data representative of” the relevant parameter/parameter value if not explicitly stated (unless the context demands otherwise). The data may be in any way indicative of the relevant parameter/parameter value, and may be directly or indirectly indicative thereof. In this description, reference has been made to various examples. The description of features or functions in relation to an example indicates that those features or functions are present in that example. The use of the term ’example’ or 'for example’, 'can’ or 'may’ in the text denotes, whether explicitly stated or not, that such features or functions are present in at least the described example, whether described as an example or not, and that they can be, but are not necessarily, present in some or all other examples. Thus 'example’, 'for example’, 'can’ or 'may’ refers to a particular instance in a class of examples. A property of the instance can be a property of only that instance or a property of the class or a property of a sub-class of the class that includes some but not all of the instances in the class.

In this description, references to "a/an/the” [feature, element, component, means ...] are used with an inclusive not an exclusive meaning and are to be interpreted as "at least one” [feature, element, component, means ...] unless explicitly stated otherwise. That is any reference to X comprising a/the Y indicates that X can comprise only one Y or can comprise more than one Y unless the context clearly indicates the contrary. If it is intended to use 'a’ or 'the’ with an exclusive meaning then it will be made clear in the context. In some circumstances the use of 'at least one’ or 'one or more’ can be used to emphasise an inclusive meaning but the absence of these terms should not be taken to infer any exclusive meaning. As used herein, "at least one of the following: <a list of two or more elements>” and "at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by "and” or "or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

The presence of a feature (or combination of features) in a claim is a reference to that feature (or combination of features) itself and also to features that achieve substantially the same technical effect (equivalent features). The equivalent features include, for example, features that are variants and achieve substantially the same result in substantially the same way. The equivalent features include, for example, features that perform substantially the same function, in substantially the same way to achieve substantially the same result.

In this description, reference has been made to various examples using adjectives or adjectival phrases to describe characteristics of the examples. Such a description of a characteristic in relation to an example indicates that the characteristic is present in some examples exactly as described and is present in other examples substantially as described.

In the above description, the apparatus described can alternatively or in addition comprise an apparatus which in some other examples comprises a distributed system of apparatus, for example, a client/server apparatus system. In examples where an apparatus provided forms (or a method is implemented as) a distributed system, each apparatus forming a component and/or part of the system provides (or implements) one or more features which collectively implement an example of the present disclosure. In some examples, an apparatus is re-configured by an entity other than its initial manufacturer to implement an example of the present disclosure by being provided with additional software, for example by a user downloading such software, which when executed causes the apparatus to implement an example of the present disclosure (such implementation being either entirely by the apparatus or as part of a system of apparatus as mentioned hereinabove).

The above description describes some examples of the present disclosure however those of ordinary skill in the art will be aware of possible alternative structures and method features which offer equivalent functionality to the specific examples of such structures and features described herein above and which for the sake of brevity and clarity have been omitted from the above description. Nonetheless, the above description should be read as implicitly including reference to such alternative structures and method features which provide equivalent functionality unless such alternative structures or method features are explicitly excluded in the above description of the examples of the present disclosure.

Whilst endeavouring in the foregoing specification to draw attention to those features of examples of the present disclosure believed to be of particular importance it should be understood that the applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not particular emphasis has been placed thereon.

The examples of the present disclosure and the accompanying claims can be suitably combined in any manner apparent to one of ordinary skill in the art. Separate references to an "example”, "in some examples” and/or the like in the description do not necessarily refer to the same example and are also not mutually exclusive unless so stated and/or except as will be readily apparent to those skilled in the art from the description. For instance, a feature, structure, process, block, step, action, or the like described in one example may also be included in other examples, but is not necessarily included.

Each and every claim is incorporated as further disclosure into the specification and the claims are embodiment(s) of the present disclosure. Further, while the claims herein are provided as comprising specific dependencies, it is contemplated that any claims can depend from any other claims and that to the extent that any alternative embodiments can result from combining, integrating, and/or omitting features of the various claims and/or changing dependencies of claims, any such alternative embodiments and their equivalents are also within the scope of the disclosure.

Claims

CLAIMS We claim:

1 . An apparatus comprising: means for receiving configuration information for enabling the apparatus to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded first packet, and the at least second packet is transferred to a recipient; and means for operating the apparatus in the operational mode based at least in part on the configuration information.

2. The apparatus of claim 1 , wherein the means for operating the apparatus in the operational mode based at least in part on the configuration information comprises: means for receiving the at least first packet; means for decoding the at least first packet; means for determining whether the at least first packet has been erroneously decoded; means for determining the information from the at least part of the erroneously decoded at least first packet; means for generating the at least second packet comprising the information from the at least part of the erroneously decoded at least first packet, wherein the generation of the at least second packet is based at least in part on determining that the at least first packet has been erroneously decoded; and means for transferring the at least second packet to the recipient.

3. The apparatus of any previous claim, wherein determining whether the at least first packet has been erroneously decoded comprises at least one of the following: detecting an error in the decoded at least first packet; detecting an error in a channel decoding process performed on the at least first packet; detecting a failure of a Cyclic Redundancy Check, CRC; or detecting a latency for the at least first packet exceeding a threshold.

4. The apparatus of any previous claim, wherein the information from the at least part of the erroneously decoded at least first packet comprises at least one of the following: one or more decoded symbols of the at least first packet; one or more hard decoded bits of the at least first packet; one or more soft coded bits indicative of one or more confidence levels of one or more hard decoded bits of the at least first packet; one or more Log Likelihood Ratio, LLR, values; one or more codewords derived from the erroneously decoded at least first packet; one or more of the most likely codewords based at least in part on soft coded bits associated with the erroneously decoded first packet; an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

5. The apparatus of any previous claim, wherein the at least second packet further comprises at least one of the following: information indicative of a state of a channel via which the at least first packet was conveyed; information indicative of a decoding process via which the at least first packet was decoded.

6. The apparatus of any previous claim, wherein the apparatus is at least one or the following: a User Equipment, UE; or a memory access device.

7. The apparatus of any previous claim, wherein transferring the at least second packet to a recipient comprises at least one of the following: passing the at least second packet to an application layer; passing the second packet from a Medium Access Control layer of the apparatus to an application layer of the apparatus; bypassing one or more radio access network protocol stack layers; or transferring the at least second packet to an application residing on the apparatus.

8. The apparatus of any previous claim, wherein the apparatus further comprises means for transmitting a request to operate in the operational mode.

9. The apparatus of claim 8, wherein the request comprises at least one of the following: an identifier of an application residing on the apparatus; or a request for a packet format of the at least second packet.

10. The apparatus of any previous claim, wherein the configuration information comprises an indication of at least one of the following: an identifier of an application residing on the apparatus; or a packet format of the at least second packet.

11. The apparatus of claim 10 when dependent upon claim 8 or 9, wherein the configuration information is based at least in part on the request.

12. The apparatus of any previous claim, wherein the at least second packet has a packet format, and wherein the packet format is pre-determined between an application of the apparatus and a second apparatus that is a source of the at least first packet.

13. The apparatus of claim 12, wherein the packet format of the at least second packet indicates whether the at least second packet is to comprise at least one of the following: an indication for identifying the at least second packet as a packet that is generated, based at least in part on the determination that the at least first packet has been erroneously decoded; an indication for identifying the at least second packet as a packet that comprises information from at least a part of the erroneously decoded at least first packet; an indication that the at least first packet was erroneously decoded; one or more decoded symbols of the at least first packet; one or more hard coded bits of the at least first packet; one or more soft coded bits indicative of one or more confidence levels of one or more hard decoded bits of the at least first packet; one or more Log Likelihood Ratio, LLR, values; one or more codewords derived from the erroneously decoded at least first packet; one or more of the most likely codewords based at least in part on soft coded bits associated with the erroneously decoded first packet; an indication of one or more segments associated with the at least first packet; or a map or index of erroneous segments.

14. The apparatus of any previous claim, wherein the configuration information comprises information for configuring the apparatus to bypass one or more layers of a radio access network stack.

15. The apparatus of any previous claim, wherein at least one of the following applies: the apparatus is a network node of a Radio Access Network; the recipient is a core node of a Radio Access Network; the recipient is a User Plane Function; or the recipient is a node of a second Radio Access Network.

16. The apparatus of any previous claim, wherein the apparatus further comprises means for requesting establishment of a link between the apparatus and a second apparatus that is a source of the at least first packet, wherein the link is configured such that, for one or more packets transmitted via the link, the apparatus operates in the operational mode.

17. The apparatus of claim 16, wherein the means for requesting establishment of the link comprises means for requesting at least one of the following: one or more layers of a radio access network stack be bypassed during the reception and/or transmission of one or more packets conveyed via a radio link; one or more layers above a Media Access Control, MAC, or Physical, PHY, layer be bypassed during a reception and/or transmission of one or more packets conveyed via a radio link; a modulation scheme be used for the transmission of one or more packets conveyed via a radio link; a modulation constellation be used for the transmission of one or more packets conveyed via a radio link; a coding scheme be used for the transmission of one or more packets conveyed via a radio link; or a code rate and/or type be used for the transmission of one or more packets conveyed via a radio link.

18. An apparatus comprising: means for receiving a request, from an apparatus, to operate in an operational mode, wherein in the operational mode: based at least in part on a determination that at least a first packet received at the apparatus has been erroneously decoded by the apparatus, at least a second packet is generated wherein the at least second packet comprises information from at least a part of the erroneously decoded at least first packet, and the at least second packet is transferred to a recipient; means for determining, based at least in part on the request, configuration information for configuring the apparatus to operate in the operational mode; and means for sending, to the apparatus, the configuration information.